[Iccrg] Re: [tcpm] ECN feedback discussion
Scheffenegger, Richard
rs at netapp.com
Sat Nov 10 16:35:12 GMT 2012
That would be my stance too...
Imho, part of why ecn has failed to get traction was/is the complex and nondeterministic way in which the end systems and the network in between are supposed to run a distributed control loop that should keep congestion (standing buffer queues/buffer overflows) at bay.
Imho, dctcp has a very good point in keeping the control loop entirely in the end systems and have a very simple, straight forward and deterministic marking scheme in the network...
I think we need first and foremost a signaling scheme that should lend itself to the most broad applications.
A counter (of some sort, however implemented) would be a huge step forward.
I'm also wondering, if there is information to be had off the exact "pattern" (in the time domain) from CE (or ECT1 too) marks...
I.e. Is a sudden jump from no marks to all marks and then a slow drop of marking probability - all in one RTT - different from a slow rise in markin probabiliy up to 100%, followed by a sudden drop to no marks? With the total number of marks in one RTT equal in both cases? Can anyone think that such a 2nd order signal might be useful, or does anyone know of research into such aspects?
Best regards,
Richard
Von meinem iPhone gesendet
Am 09.11.2012 um 09:20 schrieb "Michael Welzl" <michawe at ifi.uio.no>:
> Hi,
>
> I'd prefer a simpler approach. We haven't seen ECN happen, and trying to embed QoS in it isn't exactly going to improve the probability of success IMO.
>
> Cheers,
> Michael
>
>
> On Nov 9, 2012, at 7:21 AM, Arjuna Sathiaseelan wrote:
>
>> I think updating the behaviour of ECN would be a great idea -
>>
>> We could have different behaviours for different types of
>> communication - for e.g.
>>
>> (1) we could be less aggressive to emergency communications
>> (2) We could be more aggressive to scavenger type traffic
>> (3) We do the normal ecn behaviour inbetween
>>
>> So probably we-ve got to map QoS behaviour to ECN I guess..
>>
>> Arjuna
>>
>> On 9 November 2012 04:50, <iccrg-request at cs.ucl.ac.uk> wrote:
>>> Send Iccrg mailing list submissions to
>>> iccrg at cs.ucl.ac.uk
>>>
>>> To subscribe or unsubscribe via the World Wide Web, visit
>>> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
>>> or, via email, send a message with subject or body 'help' to
>>> iccrg-request at cs.ucl.ac.uk
>>>
>>> You can reach the person managing the list at
>>> iccrg-owner at cs.ucl.ac.uk
>>>
>>> When replying, please edit your Subject line so it is more specific
>>> than "Re: Contents of Iccrg digest..."
>>>
>>>
>>> Today's Topics:
>>>
>>> 1. Re: [tcpm] ECN feedback discussion (Michael Welzl)
>>> 2. Re: New co-chair (Eggert, Lars)
>>> 3. Re: [tcpm] ECN feedback discussion (Yuchung Cheng)
>>> 4. Re: [tcpm] ECN feedback discussion (Michael Welzl)
>>> 5. Re: Re: [tcpm] ECN feedback discussion (Mikael Abrahamsson)
>>>
>>>
>>> ----------------------------------------------------------------------
>>>
>>> Message: 1
>>> Date: Thu, 8 Nov 2012 15:11:56 +0100
>>> From: Michael Welzl <michawe at ifi.uio.no>
>>> Subject: [Iccrg] Re: [tcpm] ECN feedback discussion
>>> To: gorry at erg.abdn.ac.uk
>>> Cc: "tcpm \(tcpm at ietf.org\)" <tcpm at ietf.org>, "iccrg at cs.ucl.ac.uk
>>> list" <iccrg at cs.ucl.ac.uk>
>>> Message-ID: <2FAF37DF-F803-479B-BAFC-6DA75B817347 at ifi.uio.no>
>>> Content-Type: text/plain; charset=WINDOWS-1252; format=flowed;
>>> delsp=yes
>>>
>>> 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
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>> ------------------------------
>>>
>>> Message: 2
>>> Date: Thu, 8 Nov 2012 15:37:20 +0000
>>> From: "Eggert, Lars" <lars at netapp.com>
>>> Subject: Re: [Iccrg] New co-chair
>>> To: David Ros <David.Ros at telecom-bretagne.eu>
>>> Cc: iccrg list <iccrg at cs.ucl.ac.uk>, Internet Research Steering Group
>>> <irsg at irtf.org>
>>> Message-ID:
>>> <D4D47BCFFE5A004F95D707546AC0D7E9185E63D8 at SACEXCMBX01-PRD.hq.netapp.com>
>>>
>>> Content-Type: text/plain; charset="us-ascii"
>>>
>>> Hi David,
>>>
>>> welcome as new co-chair, and welcome to the IRSG! I have just updated the IRTF's public web site.
>>>
>>> Murari, thank you very much for your service over the years!
>>>
>>> Lars
>>> -------------- next part --------------
>>> A non-text attachment was scrubbed...
>>> Name: smime.p7s
>>> Type: application/pkcs7-signature
>>> Size: 4361 bytes
>>> Desc: not available
>>> Url : http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20121108/ba936283/smime-0001.bin
>>>
>>> ------------------------------
>>>
>>> Message: 3
>>> Date: Thu, 8 Nov 2012 16:10:38 -0500
>>> From: Yuchung Cheng <ycheng at google.com>
>>> Subject: [Iccrg] Re: [tcpm] ECN feedback discussion
>>> To: "tcpm (tcpm at ietf.org)" <tcpm at ietf.org>, "iccrg at cs.ucl.ac.uk list"
>>> <iccrg at cs.ucl.ac.uk>
>>> Message-ID:
>>> <CAK6E8=fHkd6AidYByVBoRn_xFvxQxzH=8ZDvsFdmjfDTu-prvQ at mail.gmail.com>
>>> Content-Type: text/plain; charset=ISO-8859-1
>>>
>>> Playing devil's advocate: what's the goal of advanced ECN feedback?
>>> what and whose problems are we solving?
>>>
>>> My worries are that we can design fancier stuff, in the end if it does
>>> not matter for applications, it does not matter. Is today's basic ECN
>>> not being used b/c it's too basic?
>>>
>>>
>>>
>>> ------------------------------
>>>
>>> Message: 4
>>> Date: Thu, 8 Nov 2012 17:43:46 -0500
>>> From: Michael Welzl <michawe at ifi.uio.no>
>>> Subject: [Iccrg] Re: [tcpm] ECN feedback discussion
>>> To: Yuchung Cheng <ycheng at google.com>
>>> Cc: "tcpm \(tcpm at ietf.org\)" <tcpm at ietf.org>, "iccrg at cs.ucl.ac.uk
>>> list" <iccrg at cs.ucl.ac.uk>
>>> Message-ID: <88F49B9E-F311-405A-94D8-8D12DE089F64 at ifi.uio.no>
>>> Content-Type: text/plain; charset=us-ascii
>>>
>>> We wanna have less delay, dude!
>>>
>>> Sent from my iPhone
>>>
>>> On 8. nov. 2012, at 16:10, Yuchung Cheng <ycheng at google.com> wrote:
>>>
>>>> Playing devil's advocate: what's the goal of advanced ECN feedback?
>>>> what and whose problems are we solving?
>>>>
>>>> My worries are that we can design fancier stuff, in the end if it does
>>>> not matter for applications, it does not matter. Is today's basic ECN
>>>> not being used b/c it's too basic?
>>>> _______________________________________________
>>>> tcpm mailing list
>>>> tcpm at ietf.org
>>>> https://www.ietf.org/mailman/listinfo/tcpm
>>>
>>>
>>>
>>> ------------------------------
>>>
>>> Message: 5
>>> Date: Fri, 9 Nov 2012 05:49:48 +0100 (CET)
>>> From: Mikael Abrahamsson <swmike at swm.pp.se>
>>> Subject: Re: [Iccrg] Re: [tcpm] ECN feedback discussion
>>> To: Yuchung Cheng <ycheng at google.com>
>>> Cc: "tcpm \(tcpm at ietf.org\)" <tcpm at ietf.org>, "iccrg at cs.ucl.ac.uk
>>> list" <iccrg at cs.ucl.ac.uk>
>>> Message-ID: <alpine.DEB.2.00.1211090540230.13802 at uplift.swm.pp.se>
>>> Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
>>>
>>> On Thu, 8 Nov 2012, Yuchung Cheng wrote:
>>>
>>>> My worries are that we can design fancier stuff, in the end if it does
>>>> not matter for applications, it does not matter. Is today's basic ECN
>>>> not being used b/c it's too basic?
>>>
>>> I'd imagine ECN isn't used today because nobody knows what it is and why
>>> it's good to use. It's like IPv6, it doesn't really solve anything for the
>>> individual entitiy (ISP|user|equipment vendor), but as a whole, it would
>>> be good if we had it.
>>>
>>> I would also venture to say that congestion used to happen in the core and
>>> distribution. This is not really the case anymore, now congestion happens
>>> much closer to the edge, which is also the place where there is least
>>> homogenous control and thus harder to coordinate any technology.
>>>
>>> I have been running with ECN on, on most my machines for years now, just
>>> to make sure it doesn't break anything. When it was first implemented in
>>> the Linux kernel, ECN broke a lot of things. PIX firewalls for instance,
>>> dropped ECN packets. This is not the case anymore as far as I can tell, I
>>> haven't noticed any ECN related problem at all since I re-enabled it, hm,
>>> 3-4 years ago perhaps.
>>>
>>> To get ECN (and other more advanced tech) into production networks, we
>>> need to be able to explain to users and manufacturers (and ISPs) what good
>>> it does, and how it can make their life metter. From the bufferbloat
>>> discussion, I'd say this is quite hard, since most don't even know how TCP
>>> works in conjunction with large buffers, much less the difference between
>>> different TCP algorithms. So teaching about benefits of ECN is quite
>>> hard.
>>>
>>> ECN is a good idea. IPv6 is a good idea. IPv6 is now happening (slowly)
>>> because IPv4 ran out. Nothing happened really for 5-10 years because IPv6
>>> didn't really solve any problem people thought they had. ECN is the same
>>> thing. ECN makes the network more efficient, in that it doesn't drop the
>>> packet if there is congestion. But how does that help the individual end
>>> user? That's harder to explain.
>>>
>>> Sorry for not being able to give any constructive suggestions on how to
>>> solve the problem of lack of ECN support, but if we can get some consensus
>>> about why ECN hasn't been implemented, perhaps that helps us making future
>>> decisions?
>>>
>>> --
>>> Mikael Abrahamsson email: swmike at swm.pp.se
>>>
>>>
>>>
>>> ------------------------------
>>>
>>> _______________________________________________
>>> Iccrg mailing list
>>> Iccrg at cs.ucl.ac.uk
>>> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
>>>
>>>
>>> End of Iccrg Digest, Vol 82, Issue 7
>>> ************************************
>>
>>
>>
>> --
>>
>> Arjuna | http://www.cl.cam.ac.uk/~as2330/
>>
>> _______________________________________________
>> Iccrg mailing list
>> Iccrg at cs.ucl.ac.uk
>> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
>
>
> _______________________________________________
> Iccrg mailing list
> Iccrg at cs.ucl.ac.uk
> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
More information about the Iccrg
mailing list