[Iccrg] Re: [tcpm] ECN feedback discussion

Emmanuel Lochin emmanuel.lochin at gmail.com
Fri Nov 9 10:27:05 GMT 2012


Hi all,

I wish to come back on the discussion concerning a "more accurate ECN
feedback".
I utterly support the following draft
draft-kuehlewind-tcpm-accurate-ecn-option and the idea that this binary
signal is not enough to clearly take an optimal decision concerning the
sending rate.

Two years ago, we drove a study to illustrate that the use of a simple ECN
counter might open the door to several schemes and methods allowing to
better assess the level of congestion and thus, react to losses in a
consistent way. See : Diana, Rémi and Lochin, Emmanuel *ECN verbose mode: a
statistical method for network path congestion estimation.* (2011) Computer
Networks, vol. 55 (n° 10). pp. 2380-2391. ISSN 1389-1286 available here :
http://oatao.univ-toulouse.fr/4779/

Enhancing ECN feedback would greatly help us to collect statistical
information in order to optimize the TCP reaction to this signal.

Emmanuel




On 9 November 2012 09:32, Scharf, Michael (Michael) <
michael.scharf at alcatel-lucent.com> wrote:

> > I have been thinking of writing a draft that updates RFC3540
> > to incorporate this for many years now, but never seriously
> > pursued it because I thought it would be best to wait until
> > Bob Briscoe is done with all his bit thievery. But he will
> > never stop, will he?  :-)
>
> While I really enjoy the technical ideas in this discussion, I am somehow
> concerned about the tone here... I think the community must really
> understand that *burglary* is not at all an appropriate approach for
> getting the beloved bits in the TCP header. Instead, quite obviously, the
> right thing to do is bribery of the TCPM chairs ;)
>
> Michael
> _______________________________________________
> tcpm mailing list
> tcpm at ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20121109/d709a4c3/attachment.html


More information about the Iccrg mailing list