[Iccrg] Re: Iccrg Digest, Vol 81, Issue 10

arjuna.sathiaseelan@gmail.com (Arjuna Sathiaseelan) Mon, 29 October 2012 19:02 UTC

From: arjuna.sathiaseelan@gmail.com
Date: Mon, 29 Oct 2012 19:02:18 +0000
Subject: [Iccrg] Re: Iccrg Digest, Vol 81, Issue 10
In-Reply-To: <508e7166.a1c5d80a.7d20.3ed0SMTPIN_ADDED@mx.google.com>
References: <508e7166.a1c5d80a.7d20.3ed0SMTPIN_ADDED@mx.google.com>
Message-ID: <CAPaG1AmmsRyWMQ8uNZRF7V=CL7AOkhsj71RcMuaNwURKwF2p+A@mail.gmail.com>
X-Date: Mon Oct 29 19:02:18 2012

something related here :
http://datatracker.ietf.org/doc/draft-carlberg-tsvwg-ecn-reactions/

arjuna

On 29 October 2012 12:07,  <iccrg-request@cs.ucl.ac.uk> wrote:
> Send Iccrg mailing list submissions to
>         iccrg@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@cs.ucl.ac.uk
>
> You can reach the person managing the list at
>         iccrg-owner@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: Why don't we stop treating ECN and loss similarly?
>       (Jo?o Taveira Ara?jo)
>    2. Re: Why don't we stop treating ECN and loss similarly?
>       (Jo?o Taveira Ara?jo)
>    3. Re: Why don't we stop treating ECN and loss similarly?
>       (Michael Welzl)
>    4. Re: Why don't we stop treating ECN and loss similarly?
>       (Mikael Abrahamsson)
>    5. Re: Why don't we stop treating ECN and loss similarly?
>       (ken carlberg)
>    6. Re: Why don't we stop treating ECN and loss similarly?
>       (Mikael Abrahamsson)
>    7. Re: Why don't we stop treating ECN and loss similarly?
>       (ken carlberg)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sun, 28 Oct 2012 17:27:20 +0000
> From: Jo?o Taveira Ara?jo <lists@syshex.com>
> Subject: Re: [Iccrg] Why don't we stop treating ECN and loss
>         similarly?
> To: iccrg <iccrg@cs.ucl.ac.uk>
> Message-ID: <1351445028-sup-2809@moonloop.syshex.com>
> Content-Type: text/plain; charset=UTF-8
>
> Hi,
>
> Excerpts from Lachlan Andrew's message of Sun Oct 28 01:56:33 +0100 2012:
>> Greetings John,
>>
>> On 27 October 2012 22:55, John Leslie <john@jlc.net> wrote:
>> >
>> >    As Bob has pointed out, theory clearly shows that the less-aggressive
>> > reaction-to-loss will starve the more-aggressive...
>>
>> Could you remind us which theory shows that?  It sounds rather
>> counter-intuitive.
>
> The term aggressive is a bit of a misnomer in this context. I believe
> what was implied was that flows which back off less in times of contention
> starve those which back off more.
>
> Joao.
>
>>
>> Thanks,
>> Lachlan
>>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Sun, 28 Oct 2012 18:13:31 +0000
> From: Jo?o Taveira Ara?jo <lists@syshex.com>
> Subject: Re: [Iccrg] Why don't we stop treating ECN and loss
>         similarly?
> To: iccrg <iccrg@cs.ucl.ac.uk>
> Message-ID: <1351445338-sup-8866@moonloop.syshex.com>
> Content-Type: text/plain; charset=UTF-8
>
> Hi,
>
> Excerpts from Michael Welzl's message of Sat Oct 27 10:26:59 +0100 2012:
>> Hi,
>>
>> Here's an idea, inspired by something Bob Briscoe posted to the TSVWG
>> list recently in a discussion of draft-carlberg-tsvwg-ecn-reactions.
>> However, this possibly stupid idea is my own responsibility alone  :-)
>>
>>
>> According to RFC 3168, senders must react to ECN just as if packets
>> had been dropped. This is to maintain fairness between ECN-compatible
>> and non-compatible flows.
>> Because of this requirement, AQMs cannot ECN-mark packets more
>> aggressively than it drops packets from non-ECN-capable flows - else
>> ECN-marked flows would be at a disadvantage.
>>
>> We have seen various non-standard congestion control behaviors can co-
>> exist reasonably well with standard TCP in practice. If it was
>> possible to have a milder congestion reaction to ECN-based reaction,
>> it would also be possible to ECN-mark packets earlier, leading to a
>> bigger advantage for everyone using ECN. And none of this is possible
>> when we have the "treat an ECN mark just like loss" rule in place.
>>
>> Hence, my question: to incentivize ECN usage and enable better
>> behavior when it's used, shouldn't we remove this rule?
>>
>> Note that this is not even about a more fine-grain interpretation of
>> ECN feedback - it's more like an intermediate step.
>
> With research hat off, I'd be wary of making such changes.
> As you point out, the specification of ECN is overly conservative (more
> so than DECbit for example), but I believe TCP fairness alone was only
> part of it. The Source Quench option had proved a debacle because
> gateways had no expectation on how hosts would react, and hosts had
> little indication on what the option was intended to signal. That SQ
> ended being rendered useless through a myriad of interpretations may
> explain why ECN adhered so strictly to well understood principles and
> concisely specified behaviour.
>
> It would be simpler to answer your thought experiment if you take it one
> step further: what would you replace the rule with, and how would the
> coexistence of both not be detrimental to ECN as a standard?
>
> Joao
>
>> I'm curious what everyone thinks... am I missing something?
>>
>> Cheers,
>> Michael
>>
>
>
>
> ------------------------------
>
> Message: 3
> Date: Mon, 29 Oct 2012 09:03:58 +0100
> From: Michael Welzl <michawe@ifi.uio.no>
> Subject: Re: [Iccrg] Why don't we stop treating ECN and loss
>         similarly?
> To: Jo?o Taveira Ara?jo <lists@syshex.com>
> Cc: iccrg <iccrg@cs.ucl.ac.uk>
> Message-ID: <2E6D3BD2-034D-4E2C-872B-D11A4C4330D9@ifi.uio.no>
> Content-Type: text/plain; charset=iso-8859-1
>
> Hi,
>
> inline:
>
> On 28. okt. 2012, at 19:13, Jo?o Taveira Ara?jo wrote:
>
>> Hi,
>>
>> Excerpts from Michael Welzl's message of Sat Oct 27 10:26:59 +0100 2012:
>>> Hi,
>>>
>>> Here's an idea, inspired by something Bob Briscoe posted to the TSVWG
>>> list recently in a discussion of draft-carlberg-tsvwg-ecn-reactions.
>>> However, this possibly stupid idea is my own responsibility alone  :-)
>>>
>>>
>>> According to RFC 3168, senders must react to ECN just as if packets
>>> had been dropped. This is to maintain fairness between ECN-compatible
>>> and non-compatible flows.
>>> Because of this requirement, AQMs cannot ECN-mark packets more
>>> aggressively than it drops packets from non-ECN-capable flows - else
>>> ECN-marked flows would be at a disadvantage.
>>>
>>> We have seen various non-standard congestion control behaviors can co-
>>> exist reasonably well with standard TCP in practice. If it was
>>> possible to have a milder congestion reaction to ECN-based reaction,
>>> it would also be possible to ECN-mark packets earlier, leading to a
>>> bigger advantage for everyone using ECN. And none of this is possible
>>> when we have the "treat an ECN mark just like loss" rule in place.
>>>
>>> Hence, my question: to incentivize ECN usage and enable better
>>> behavior when it's used, shouldn't we remove this rule?
>>>
>>> Note that this is not even about a more fine-grain interpretation of
>>> ECN feedback - it's more like an intermediate step.
>>
>> With research hat off, I'd be wary of making such changes.
>> As you point out, the specification of ECN is overly conservative (more
>> so than DECbit for example), but I believe TCP fairness alone was only
>> part of it. The Source Quench option had proved a debacle because
>> gateways had no expectation on how hosts would react, and hosts had
>> little indication on what the option was intended to signal. That SQ
>> ended being rendered useless through a myriad of interpretations may
>> explain why ECN adhered so strictly to well understood principles and
>> concisely specified behaviour.
>
> Hm, I can see that -
>
>>
>> It would be simpler to answer your thought experiment if you take it one
>> step further: what would you replace the rule with, and how would the
>> coexistence of both not be detrimental to ECN as a standard?
>
> ... and THIS is interesting research to pursue!
>
> Perhaps some of the ideas for reacting to a finer-grain ECN signal will lead to an answer to that.
>
> Cheers,
> Michael
>
>
>
>
> ------------------------------
>
> Message: 4
> Date: Mon, 29 Oct 2012 09:56:14 +0100 (CET)
> From: Mikael Abrahamsson <swmike@swm.pp.se>
> Subject: Re: [Iccrg] Why don't we stop treating ECN and loss
>         similarly?
> To: iccrg <iccrg@cs.ucl.ac.uk>
> Message-ID: <alpine.DEB.2.00.1210290947280.28593@uplift.swm.pp.se>
> Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII
>
> On Mon, 29 Oct 2012, Michael Welzl wrote:
>
>> Perhaps some of the ideas for reacting to a finer-grain ECN signal will
>> lead to an answer to that.
>
> As far as I can tell, ECN has decent end-system support, but very limited
> network support. I don't know of any major core routing platform that
> supports setting ECN in a RED configuration instead of dropping the
> packet (last I checked this was 1.5 years ago, but talking to vendors
> indicated very little interest).
>
> I'm also seeing buffer depth going down over time (see bufferbloat
> discussion, plus prolifiration of L3 switches with minimal onboard buffers
> instead of larger classical router ones), which means that it's even
> harder than before to justify ECN as nothing in a live network will really
> act on ECN being used or not by the end system. If someone else has other
> information, I'd like to know.
>
> Perhaps it would be valuable to write some text about the state of ECN
> support right now, and then a plan to increase value for ECN so we can get
> it adopted. Current state of affairs is that few care about ECN because
> nobody is asking for it (same as with IPv6), so there is little commercial
> incentive to get it implemented. I feel most talk about ECN is from
> academia with little current real world implications. I'd like to see this
> changed, but I don't really know how. Changing the standards to
> implementing ECN actually brings improvement to both ISP and end user
> might be a good first step towards a world where ECN is actually used.
>
> --
> Mikael Abrahamsson    email: swmike@swm.pp.se
>
>
>
> ------------------------------
>
> Message: 5
> Date: Mon, 29 Oct 2012 06:10:00 -0400
> From: ken carlberg <carlberg@g11.org.uk>
> Subject: Re: [Iccrg] Why don't we stop treating ECN and loss
>         similarly?
> To: Mikael Abrahamsson <swmike@swm.pp.se>
> Cc: iccrg <iccrg@cs.ucl.ac.uk>
> Message-ID: <0018B283-A54E-4A52-95E0-D44CA12D5B63@g11.org.uk>
> Content-Type: text/plain; charset=us-ascii
>
>
> On Oct 29, 2012, at 4:56 AM, Mikael Abrahamsson wrote:
>
>> Perhaps it would be valuable to write some text about the state of ECN support right now, and then a plan to increase value for ECN so we can get it adopted. Current state of affairs is that few care about ECN because nobody is asking for it (same as with IPv6), so there is little commercial incentive to get it implemented. I feel most talk about ECN is from academia with little current real world implications. I'd like to see this changed, but I don't really know how. Changing the standards to implementing ECN actually brings improvement to both ISP and end user might be a good first step towards a world where ECN is actually used.
>
> this topic has come up before on this list.  about 2.5 years ago, an engineer in my office did some tests and found that IP service providers do one of three things with the ToS field (that have some combination of non-zero markings): (a) they let them pass through unchanged, (b) they clear out the diff-serv field, but leave the ECN field untouched, and (c) they clear the entire ToS byte.
>
> Tony Li made the good suggestion that if folks are concerned about (c), they should go to places like NANOG and talk to the operators about this.
>
> as for interest in ECN, it exists in some planned deployments of LTE for the toll-quality VoIP applications/services.
>
> -ken
>
>
>
>
> ------------------------------
>
> Message: 6
> Date: Mon, 29 Oct 2012 12:10:23 +0100 (CET)
> From: Mikael Abrahamsson <swmike@swm.pp.se>
> Subject: Re: [Iccrg] Why don't we stop treating ECN and loss
>         similarly?
> To: ken carlberg <carlberg@g11.org.uk>
> Cc: iccrg <iccrg@cs.ucl.ac.uk>
> Message-ID: <alpine.DEB.2.00.1210291209260.28593@uplift.swm.pp.se>
> Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
>
> On Mon, 29 Oct 2012, ken carlberg wrote:
>
>> as for interest in ECN, it exists in some planned deployments of LTE for
>> the toll-quality VoIP applications/services.
>
> Really? Do you have some pointers to this, my understanding was that VoLTE
> would be on a dedicated bearer with that kind of QoS that 3GPP always has
> done (per bearer, but doing FIFO within the bearer).
>
> --
> Mikael Abrahamsson    email: swmike@swm.pp.se
>
>
>
> ------------------------------
>
> Message: 7
> Date: Mon, 29 Oct 2012 07:30:26 -0400
> From: ken carlberg <carlberg@g11.org.uk>
> Subject: Re: [Iccrg] Why don't we stop treating ECN and loss
>         similarly?
> To: Mikael Abrahamsson <swmike@swm.pp.se>
> Cc: iccrg <iccrg@cs.ucl.ac.uk>
> Message-ID: <776D88CC-F632-44B6-B400-07F97DFE818E@g11.org.uk>
> Content-Type: text/plain; charset=us-ascii
>
> part of my understanding comes from individual conversations with carriers from a couple of different countries, so I can't provide a pointer to that.  But indirectly, you can see some of the interest in the form of some standards work in the ITU with participation by industry on H.248.82  "Gateway Control Protocol: Explict Congestion Notification Support", from SG 16 dated May 2012.  And there are other addendums to this base document, but I don't follow SG 16 closely.
>
> -ken
>
>
> On Oct 29, 2012, at 7:10 AM, Mikael Abrahamsson wrote:
>
>> On Mon, 29 Oct 2012, ken carlberg wrote:
>>
>>> as for interest in ECN, it exists in some planned deployments of LTE for the toll-quality VoIP applications/services.
>>
>> Really? Do you have some pointers to this, my understanding was that VoLTE would be on a dedicated bearer with that kind of QoS that 3GPP always has done (per bearer, but doing FIFO within the bearer).
>>
>> --
>> Mikael Abrahamsson    email: swmike@swm.pp.se
>
>
>
>
> ------------------------------
>
> _______________________________________________
> Iccrg mailing list
> Iccrg@cs.ucl.ac.uk
> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
>
>
> End of Iccrg Digest, Vol 81, Issue 10
> *************************************



-- 
Regards
Arjuna
http://about.me/arjuna.sathiaseelan