[Iccrg] Incentives for ECN

[ken carlberg]

sorry, I probably wasn't clear enough in my response.  I agree that it would be helpful to add incentives for end-host support of ECN.  And I find what Lachlan has proposed as interesting, though it would be nice to see a more extensive description of the ideas.  And perhaps in following John's point of how this could be done, perhaps an experimental draft-rfc could be written in order for the wider community to comment on.

However, the end-point part of the ECN model is only one part of the picture of where we need more deployed support.  A while back, one of my interns did some testing and found that a number of ISPs zero out the ECN field in IP packets, thereby nulling any potential ECN support for end-to-end paths transiting that ISP.  And this needs to be addressed regardless of what ever additional end-host support is used to encourage the use of ECN.

-ken


On Jul 15, 2011, at 9:17 AM, Michael Welzl wrote:

> ... but from an endpoint's perspective, relying on ECN in addition to loss is then no worse than relying on loss alone.
> 
> So this doesn't seem to be a reason for an endpoint not to use ECN as Lachlan/Jana suggested.
> 
> Cheers,
> Michael
> 
> 
> On Jul 15, 2011, at 3:00 PM, ken carlberg wrote:
> 
>> There is also the issue of some ISPs zero'ing out the entire old ToS byte instead of only the diff-serv code points.  CONEX is one indirect incentive to change this practice so as to not touch the ECN bits in the IP header, but I think a stronger incentive is needed.  The only thing that comes to mind is non-technical -- simply putting up a wiki page that identifies the ISPs that zero out the ECN bits and hope that they can be nudged (shamed?) into changing their practices.
>> 
>> -ken
>> 
>> 
>> On Jul 15, 2011, at 8:27 AM, John Leslie wrote:
>> 
>>> Lachlan Andrew <lachlan.andrew at gmail.com> wrote:
>>>> 
>>>> There was some discussion on LEDBAT recently about how to motivate
>>>> users to set the "ECN capable" bit  on LEDBAT flows, which Jana has
>>>> suggested may be better followed up in ICCRG.
>>> 
>>> True...
>>> 
>>>> My understanding is that it is "essentially" impossible to give an
>>>> incentive if we follow the letter of RFC3168, which says ECN must be
>>>> treated "essentially" identically to loss.
>>> 
>>> That requirement has proven less than helpful.
>>> 
>>>> That requirement was written in the days when "TCP friendliness" was
>>>> seen as essential. These days, there are many proposals that do not
>>>> aim for TCP friendliness (either being less aggressive like LEDBAT,
>>>> or more aggressive like CUBIC, HTCP, CTCP, ...).  I think it is time
>>>> to revisit the requirement that ECN be treated the same as loss.
>>> 
>>> I thoroughly agree -- but _how_ do we revisit it?
>>> 
>>> As a research question, that's entirely appropriate for ICCRG.
>>> 
>>>> People may argue that if one flow backs off less because it is
>>>> receiving ECN instead of loss, then this is "unfair" to the one
>>>> experiencing loss.  I would argue that "fair" = "no incentive".
>>> 
>>> I always argue that "fair" is one grade below "good" ;^)
>>> 
>>> But I must agree "fair" and "incentive" are often mutually
>>> exclusive. :^(
>>> 
>>>> I would propose that the ICCRG assess any new congestion control
>>>> algorithm (for "safety", "fairness" or whatever) on the assumption
>>>> that the flow may receive either ECN or loss while competing flows
>>>> receive loss.  If this gives acceptable performance, then there is no
>>>> need to require equal treatment of ECN and loss.
>>> 
>>> Interesting...
>>> 
>>> I would suggest that the essential feature of ECN is that it delivers
>>> a congestion signal _sooner_ -- so a CC algorithm which _initially_
>>> backs off more quickly upon receipt of an ECN mark, but after a few RTTs
>>> perhaps is more aggresive than vanilla-TCP upon recognizing a loss is
>>> a concept worth research.
>>> 
>>>> Of course, any such algorithm is not RFC3168 *compliant*, but it can
>>>> still be RFC3168 *compatible*.
>>> 
>>> :^)
>>> 
>>> --
>>> John Leslie <john at jlc.net>
>>> 
>>> _______________________________________________
>>> 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
> 
> 
> _______________________________________________
> Iccrg mailing list
> Iccrg at cs.ucl.ac.uk
> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg