[Iccrg] Incentives for ECN

[Qazi, Ihsan Ayyub]

I agree with the points Lachlan made. I think it is useful to ask: "What is an acceptable response to ECN when competing with flows that respond to loss?" I think new protocols should at least not starve flows responding to loss. Beyond that, there needs to be more deliberation within the community about how aggressive a response is okay.

regards,
Ihsan

Ihsan Ayyub Qazi
Postdoctoral Research Fellow
Centre for Advanced Internet Architectures (CAIA)
Melbourne, Australia
http://caia.swin.edu.au/cv/iqazi/
______________________________
________________________________________
From: iccrg-bounces at cs.ucl.ac.uk [iccrg-bounces at cs.ucl.ac.uk] On Behalf Of Lachlan Andrew [lachlan.andrew at gmail.com]
Sent: Friday, July 15, 2011 5:00 AM
To: iccrg
Subject: [Iccrg] Incentives for ECN

Greetings all,

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.

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

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

Of course, any such algorithm is not RFC3168 *compliant*, but it can
still be RFC3168 *compatible*.

Thoughts?

Lachlan

--
Lachlan Andrew  Centre for Advanced Internet Architectures (CAIA)
Swinburne University of Technology, Melbourne, Australia
<http://caia.swin.edu.au/cv/landrew>
Ph +61 3 9214 4837

_______________________________________________
Iccrg mailing list
Iccrg at cs.ucl.ac.uk
http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg