[Iccrg] Re: [tcpm] ECN feedback discussion

[Michael Welzl]

... 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
>>
>
>