[Iccrg] Incentives for ECN

[ken carlberg]

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