<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:times new roman,new york,times,serif;font-size:12pt"><div>I know of base stations that drop IP packets in advance as a way to quench Internet side incoming (download) traffic<br>This type of use case could be an incentive for operators to use ECN, without throwing away application data.<br><br>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.<br><br>Dirceu<br></div><div style="font-family:times new roman, new york, times, serif;font-size:12pt"><br><div style="font-family:arial, helvetica, sans-serif;font-size:13px"><font face="Tahoma" size="2"><hr size="1"><b><span style="font-weight: bold;">From:</span></b> ken carlberg <carlberg@g11.org.uk><br><b><span
style="font-weight: bold;">To:</span></b> Michael Welzl <michawe@ifi.uio.no><br><b><span style="font-weight: bold;">Cc:</span></b> iccrg list <iccrg@cs.ucl.ac.uk><br><b><span style="font-weight: bold;">Sent:</span></b> Fri, July 15, 2011 6:43:44 AM<br><b><span style="font-weight: bold;">Subject:</span></b> Re: [Iccrg] Incentives for ECN<br></font><br>
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.<br><br>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.<br><br>-ken<br><br><br>On Jul 15, 2011, at 9:17 AM, Michael Welzl
wrote:<br><br>> ... but from an endpoint's perspective, relying on ECN in addition to loss is then no worse than relying on loss alone.<br>> <br>> So this doesn't seem to be a reason for an endpoint not to use ECN as Lachlan/Jana suggested.<br>> <br>> Cheers,<br>> Michael<br>> <br>> <br>> On Jul 15, 2011, at 3:00 PM, ken carlberg wrote:<br>> <br>>> 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.<br>>> <br>>> -ken<br>>> <br>>> <br>>> On Jul 15, 2011, at
8:27 AM, John Leslie wrote:<br>>> <br>>>> Lachlan Andrew <<a ymailto="mailto:lachlan.andrew@gmail.com" href="mailto:lachlan.andrew@gmail.com">lachlan.andrew@gmail.com</a>> wrote:<br>>>>> <br>>>>> There was some discussion on LEDBAT recently about how to motivate<br>>>>> users to set the "ECN capable" bit on LEDBAT flows, which Jana has<br>>>>> suggested may be better followed up in ICCRG.<br>>>> <br>>>> True...<br>>>> <br>>>>> My understanding is that it is "essentially" impossible to give an<br>>>>> incentive if we follow the letter of RFC3168, which says ECN must be<br>>>>> treated "essentially" identically to loss.<br>>>> <br>>>> That requirement has proven less than helpful.<br>>>> <br>>>>> That requirement was written in the days when "TCP friendliness"
was<br>>>>> seen as essential. These days, there are many proposals that do not<br>>>>> aim for TCP friendliness (either being less aggressive like LEDBAT,<br>>>>> or more aggressive like CUBIC, HTCP, CTCP, ...). I think it is time<br>>>>> to revisit the requirement that ECN be treated the same as loss.<br>>>> <br>>>> I thoroughly agree -- but _how_ do we revisit it?<br>>>> <br>>>> As a research question, that's entirely appropriate for ICCRG.<br>>>> <br>>>>> People may argue that if one flow backs off less because it is<br>>>>> receiving ECN instead of loss, then this is "unfair" to the one<br>>>>> experiencing loss. I would argue that "fair" = "no incentive".<br>>>> <br>>>> I always argue that "fair" is one grade below "good" ;^)<br>>>> <br>>>> But I must agree "fair" and
"incentive" are often mutually<br>>>> exclusive. :^(<br>>>> <br>>>>> I would propose that the ICCRG assess any new congestion control<br>>>>> algorithm (for "safety", "fairness" or whatever) on the assumption<br>>>>> that the flow may receive either ECN or loss while competing flows<br>>>>> receive loss. If this gives acceptable performance, then there is no<br>>>>> need to require equal treatment of ECN and loss.<br>>>> <br>>>> Interesting...<br>>>> <br>>>> I would suggest that the essential feature of ECN is that it delivers<br>>>> a congestion signal _sooner_ -- so a CC algorithm which _initially_<br>>>> backs off more quickly upon receipt of an ECN mark, but after a few RTTs<br>>>> perhaps is more aggresive than vanilla-TCP upon recognizing a loss is<br>>>> a concept worth
research.<br>>>> <br>>>>> Of course, any such algorithm is not RFC3168 *compliant*, but it can<br>>>>> still be RFC3168 *compatible*.<br>>>> <br>>>> :^)<br>>>> <br>>>> --<br>>>> John Leslie <<a ymailto="mailto:john@jlc.net" href="mailto:john@jlc.net">john@jlc.net</a>><br>>>> <br>>>> _______________________________________________<br>>>> Iccrg mailing list<br>>>> <a ymailto="mailto:Iccrg@cs.ucl.ac.uk" href="mailto:Iccrg@cs.ucl.ac.uk">Iccrg@cs.ucl.ac.uk</a><br><span>>>> <a target="_blank" href="http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg">http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg</a></span><br>>> <br>>> <br>>> _______________________________________________<br>>> Iccrg mailing list<br>>> <a ymailto="mailto:Iccrg@cs.ucl.ac.uk"
href="mailto:Iccrg@cs.ucl.ac.uk">Iccrg@cs.ucl.ac.uk</a><br>>> <a href="http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg" target="_blank">http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg</a><br>> <br>> <br>> _______________________________________________<br>> Iccrg mailing list<br>> <a ymailto="mailto:Iccrg@cs.ucl.ac.uk" href="mailto:Iccrg@cs.ucl.ac.uk">Iccrg@cs.ucl.ac.uk</a><br>> <a href="http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg" target="_blank">http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg</a><br><br><br>_______________________________________________<br>Iccrg mailing list<br><a ymailto="mailto:Iccrg@cs.ucl.ac.uk" href="mailto:Iccrg@cs.ucl.ac.uk">Iccrg@cs.ucl.ac.uk</a><br><a href="http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg" target="_blank">http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg</a><br></div></div>
</div></body></html>