[Iccrg] Re: Why don't we stop treating ECN and loss similarly

[John Leslie]

Ingemar Johansson S <ingemar.s.johansson at ericsson.com> wrote:
> 
>... It is doable and sometime beneficial to treat ECN and implicit
> signals of congestion (delay, packet loss) differently. We explored
> the possibilities in 
> http://www.tschofenig.priv.at/cc-workshop/irtf_iab-ccirtcpaper4.pdf 

... demonstrating that early ECN marking, signaling a condition where
no packet drop is expected yet, enables a smooth adaptation of sending
rate.

> The trick we did was to include the channel conditions into the ECN
> decision meaning that the cost per transmitted bit is included,

   Alas, the paper itself didn't make the ECN-marking algorithm clear.
(And I'm afraid "cost per transmitted bit" isn't entirely clear either.)

> this and the combination of only a limited decrease of the bitrate
> (~20%) gives a dramatically improved performance compared to delay
> based rate adaptation.

   As one would expect, but it's always good to have data to back it up.

> ECN with cost per transmitted bit only makes sense with wireless
> access as it is only then the cost may differ between the terminals.

   Indeed, gathering similar data for all-ethernet networks would be
useful. IMHO, it's good to consider a path "congested" long before
packet drop is inevitable. To some degree, as soon as you have two
packets ready to send, there is _some_ congestion which might be worth
notifying.

   In an ideal world, we could pass on explicit notification of time-
in-queue -- and I believe there is valuable research in exploring
different possible reactions to such a signal.

   Clearly, there is value in ECN feedback if the response to ECN is
allowed to be proportionate to the actual congestion signal instead
of "the same as packet loss". In a Research Group, we can explore that.

>...
> A tough question is .. How is the end user made aware of the
> differentiated ECN and drop behavior?. 

   The right way is to _ask_ for it.

   Alas, IPv6 doesn't do much better than IPv4 at enabling this. The
mere existence of ECN-enabled proves nothing about what level of
ECN-marking is desired. For the big-I internet, something hidden in
a destination option is useless; but we could use that for research...

--
John Leslie <john at jlc.net>