[Iccrg] Re: [tcpm] ECN feedback discussion

[Michael Welzl]

If your plan is to, in doing so, update RFC3540, I'd love to be a part  
of it. If the ECN nonce is used, it's a low hanging fruit to also use  
it to sometimes detect spurious loss events:
http://heim.ifi.uio.no/~michawe/research/projects/spurious/index.html

I have been thinking of writing a draft that updates RFC3540 to  
incorporate this for many years now, but never seriously pursued it  
because I thought it would be best to wait until Bob Briscoe is done  
with all his bit thievery. But he will never stop, will he?  :-)

So, if possible, I'd love to be a part of this.

Cheers,
Michael


On Nov 8, 2012, at 3:06 PM, gorry at erg.abdn.ac.uk wrote:

> Yes - and I plan to write an I-D on this, because I think we could  
> perhaps
> move forward with this discussion in parallel with the more accurate  
> ECN.
>
> Gorry
>
>> ... but the nonce could still be used, somehow - it's just that you
>> risk more queue growth with every ECT(0) packet.
>>
>> So you could mostly use ECT(1)'s, but occasionally, use both ECT(0)'s
>> and ECT(1)'s. In doing so, you risk some more queue growth - but this
>> tests the receiver and might be good enough in the long run, as the
>> notion is to stop believing the receiver once the receiver was found
>> to cheat.
>>
>> Cheers,
>> Michael
>>
>>
>> On Nov 8, 2012, at 1:30 PM, gorry at erg.abdn.ac.uk wrote:
>>
>>> I'm also really interested in doing better than current ECN.
>>>
>>> ECN Nonce behaviour using ECT(1) was defined in RFC 3168, and the
>>> reaction
>>> is defined in the (still) experimental RFC 3540.
>>>
>>> The ECN nonce can detect remarking NON-ECT packets to ECT and can  
>>> also
>>> detect misbehaving transport receivers hiding CE from the transport
>>> sender. My own opinion is that if we do see more deployment of ECN
>>> (I do
>>> hope so) - we do need this sort of mechanism, not to verify every
>>> segment,
>>> but at least to be able to detect paths/endpoints where the ACK
>>> information is simply invalid.
>>>
>>> DCCP was mentioned in the thread, RFC 4340, took the view that ECN
>>> nonce
>>> needed to be supported and the ECN Nonce Echo field is encoded in
>>> acknowledgement options.  "Each DCCP sender SHOULD set ECN Nonces on
>>> its
>>> packets and remember which packets had nonces."
>>>
>>>
>>> Gorry
>>>
>>> P.S. Also note, if we do get to plans for new use of ECN this is
>>> likely to
>>> be a TSVWG item - since it effects much more than TCP.
>>>
>>>> Great idea, I'd love for this semantic shift to happen!
>>>>
>>>>
>>>> On Nov 7, 2012, at 2:10 PM, Scheffenegger, Richard wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I just wanted to keep a record of these interesting remarks on the
>>>>> list, for further discussion.
>>>>>
>>>>> We discussed ECN both in TCPM and ICCRG, and this post is to start
>>>>> the discussion on the working group lists.
>>>>>
>>>>> During the TCPM session, Matt Mathis made an interesting remark on
>>>>> the microphone. To paraphrase (my understanding), current marking
>>>>> schemes (RED, CoDel, PIE,…) assume that ECN marks get treated like
>>>>> loss by the end systems.  Therefore, they employ a “low density”
>>>>> marking scheme, with marks expected at an (average) rate of around
>>>>> 3% or so at maximum.
>>>>>
>>>>> Alternative schemes, that start getting deployed at this time,  
>>>>> have
>>>>> very simple marking schemes in the network, and give more
>>>>> information to the end systems for processing and reaction  
>>>>> there. As
>>>>> a side effect, these newer schemes may run as high as 100% marking
>>>>> for certain periods (longer than a single flows RTT), so they  
>>>>> could
>>>>> be classified as “high density” marking scheme.
>>>>>
>>>>>
>>>>> Later on, Bob noted, that since ECN Nonce is virtually nonexistent
>>>>> (I know only one stack with partial support), why not re-define
>>>>> ECT(1) to be used by high density marking schemes, keeping ECT(0)
>>>>> for low density schemes (as deployed today). For newer stacks,  
>>>>> this
>>>>> would allow an even more fine grained reaction to ECN marking
>>>>> levels…
>>>>>
>>>>> However, ECN security aspects (Nonce) and legacy uses (ECT(1) has
>>>>> the same meaning for existing ECN stacks as ECT(0)) would not be
>>>>> addressed, but then again, current ECN is also virtually not
>>>>> deployed, according to recent studies.
>>>>>
>>>>> Of course, such a shift in the semantics of ECT(0) vs ECT(1) would
>>>>> also need to have an impact on the future signaling  / feedback
>>>>> scheme used for TCP (DCCP and SCTP would be able to cope already,
>>>>> afaik).
>>>>>
>>>>> Best regards,
>>>>>
>>>>> Richard Scheffenegger
>>>>>
>>>>> _______________________________________________
>>>>> tcpm mailing list
>>>>> tcpm at ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/tcpm
>>>>
>>>> _______________________________________________
>>>> tcpm mailing list
>>>> tcpm at ietf.org
>>>> https://www.ietf.org/mailman/listinfo/tcpm
>>>>
>>>
>>>
>>
>
>