[Iccrg] Incentives for ECN

[Dirceu Cavendish]

I know of base stations that drop IP packets in advance as a way to quench 
Internet side incoming (download) traffic
This type of use case could be an incentive for operators to use ECN, without 
throwing away application data.

And BTW, imho, ECNs being treated as loss at end-points may present a 
dis-incentive for end-points to react to ECNs at all, since the CA designer may 
find cwnd exponential decrease too drastic a measure to be taken when receiving 
ECNs.

Dirceu




________________________________
From: ken carlberg <carlberg at g11.org.uk>
To: Michael Welzl <michawe at ifi.uio.no>
Cc: iccrg list <iccrg at cs.ucl.ac.uk>
Sent: Fri, July 15, 2011 6:43:44 AM
Subject: Re: [Iccrg] Incentives for ECN

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


_______________________________________________
Iccrg mailing list
Iccrg at cs.ucl.ac.uk
http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20110715/70a9a245/attachment.html