[Iccrg] Incentives for ECN

[John Leslie]

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>