[Iccrg] Re: [tcpm] ECN feedback discussion
Scheffenegger, Richard
rs at netapp.com
Sat Nov 10 16:35:08 GMT 2012
No, the sender may react differently to the same network signal based on its notion of quality requirements. I'm not supportive of entangling ECN with QoS and complicating things for network operators
Best regards,
Richard
Von meinem iPhone gesendet
Am 09.11.2012 um 01:23 schrieb "Arjuna Sathiaseelan" <arjuna.sathiaseelan at gmail.com>:
> 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
More information about the Iccrg
mailing list