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

[Ingemar Johansson S]

Hi

The actual ECN marking algos in LTE are likely to be proprietary, this is quite similar to the actual packet/user scheduling which is also proprietary.

/Ingemar

-----Original Message-----
From: John Leslie [mailto:john at jlc.net] 
Sent: den 31 oktober 2012 15:36
To: Ingemar Johansson S
Cc: iccrg at cs.ucl.ac.uk
Subject: Re: [Iccrg] Re: Why don't we stop treating ECN and loss similarly

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>