[Iccrg] Incentives for ECN
lachlan.andrew at gmail.com
Fri Jul 15 10:00:20 BST 2011
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*.
Lachlan Andrew Centre for Advanced Internet Architectures (CAIA)
Swinburne University of Technology, Melbourne, Australia
Ph +61 3 9214 4837
More information about the Iccrg