[Iccrg] Re: [tcpm] ECN feedback discussion

[Scheffenegger, Richard]

Hi Michael,

If both ect1 and ce signify some kind of congestion, having the sender "probe" ect1 is a noisy business (in the sense that there is no guarantee that the ect1 from the sender makes it all the way to the receiver. Hypothetically, the first part of the path might "eat" ect1 
And the 2nd half expirience congestion...

(probing would mask true marks always. A mechanism to probabilistically test this is still possible)

Rgds
    Richard

Von meinem iPhone gesendet

Am 08.11.2012 um 07:59 schrieb "Michael Welzl" <michawe at ifi.uio.no>:

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