[Iccrg] Incentives for ECN

[Michael Welzl]

... 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