[e2e] Codel and Wireless

KUHN Nicolas Nicolas.Kuhn at isae.fr
Thu Dec 5 00:44:11 PST 2013 

Dear all,

These discussions remind me a lot about the target value of LEDBAT.
Indeed, without clear comparative studies [at least from what I know - 
I would be glad to be wrong], the target was said in the RFC to be set 
up to 100 ms. However, we measured that in a long delay path, these 
100ms were not optimal [0]. Although the setting the target value to 5 
ms is not optimal neither, we believe that one should not claim the 
choice for a value for a parameter without clear evaluations.

As a result, we would like to see evaluations of the impact of these 
interval and target on the performance of CoDel. Indeed, it makes no 
sense to me to set them without justifications. As an example, in a 
document published by CableLabs [1], the authors explain that " Since we 
measure sojourn time such that it
includes this MAC latency, we simply increased the value for target (to 
10 ms in our experiments) such
that a packet arriving to an empty queue would be assured (absent RF 
congestion) that it would have a
sojourn time less than the target value.". Even though this issue may 
be solved by sf_codel, there is a clear lack of evaluations of fq_codel 
as well: do sfq and codel mix well together ?

A clear comparison between CoDel and ARED should not only discuss the 
gain in 'queuing-delay', but also discuss the deployment issues that 
CoDel may encounter if it is deployed at a large scale with arbitrary 
set parameters.

Nicolas

[0] http://www.nicta.com.au/pub?id=6691
[1] ACTIVE QUEUE MANAGEMENT ALGORITHMS FOR DOCSIS 3.0 - A Simulation 
Study of CoDel, SFQ-CoDel and PIE in DOCSIS 3.0 Networks. 2013

Le 04.12.2013 08:10, LOCHIN Emmanuel a écrit :
> Le Mercredi 4 Décembre 2013 00:45 CET, Andrew Mcgregor
> <andrewmcgr at google.com> a écrit:
>
>> Empirically, for fq_codel, long RTT flows work fine so long as RTT < 
>> 5
>> intervals, roughly speaking, and it degrades very slowly.  So 100ms 
>> is
>> about right for the internet.
>
> Dear all,
>
> I have questions about this value that appears everywhere but doesn't
> seem to have any scientific support (I mean I didn't found something
> about it). It would be great if somebody could give me any evidence
> (serious statistical study, scientific paper, ...) about this value
> explaining where does it come from. How this value has been chosen 
> and
> what about people running over long delay such as satellite broadband
> access?
>
> Emmanuel
>
>
>> On 4 December 2013 10:10, Daniel Havey <dhavey at yahoo.com> wrote:
>>
>> > On Tuesday, December 3, 2013 2:41 PM, Andrew Mcgregor <
>> > andrewmcgr at google.com> wrote:
>> >  All of which is why fq_codel is so much better... because flows 
>> queue
>> > independently, and drops are calculated per flow (although overall 
>> queue
>> > size is included implicitly via the sojourn time), the RTT delay 
>> has far
>> > less impact.  CoDel is an ingredient of an AQM system, not a 
>> desirable AQM
>> > on its own.
>> >
>> > >Makes sense to me.  We need to get the worst case RTT right.  If 
>> we set
>> > the interval to 100ms then the user with the users with larger 
>> RTTs may
>> > have issues.
>> >
>> >
>> > On 4 December 2013 08:11, Daniel Havey <dhavey at yahoo.com> wrote:
>> >
>> >
>> >
>> >
>> >
>> >
>> > On Tuesday, December 3, 2013 12:22 PM, Detlef Bosau 
>> <detlef.bosau at web.de>
>> > wrote:
>> >
>> > To my understanding, the "sojourn time" considered in CoDel is the
>> > difference between the time when a packet/leaves /a queue and the 
>> time,
>> > when this packet has /arrived /at the queue. In other words: The 
>> time a
>> > packet spends in the queue.
>> >
>> > When this time is unusually high, CoDel sees an imminent 
>> congestion and
>> > drops packets.
>> >
>> > The problem is that CoDel makes no difference whether the "sojourn 
>> time"
>> > is caused by a huge number of packets in the queue, i.e. 
>> congestion, or
>> > by a huge delivery time resulting from corruption loss and 
>> necessary
>> > retransmissions.
>> >
>> > CoDel parameters are interval and target.  If the queue drains 
>> before the
>> > interval then there shouldn't be any drops.   Also there is 
>> "leverage" from
>> > Red in a Different Light.  If CoDel decides to drop a packet from 
>> a flow
>> > that is in congestion avoidance, fast retransmit or slow start 
>> then the
>> > window is halved and the queue drains quickly.  If the flow 
>> doesn't have
>> > enough data to trigger fast retransmit then that is unfortunate 
>> for that
>> > user since they now have to wait an RTT for that packet, and it 
>> does not
>> > drain the queue very much.
>> >
>> >
>> > Hence, we have the good old loss differentiation problem. And 
>> because
>> > CoDel is particularly intended for edge routers, the disaster is 
>> placed
>> > exactly there where it is expected to happen......8-)
>> >
>> > Detlef
>> >
>> > Am 01.12.2013 22:16, schrieb Andrew Mcgregor:
>> > > I mean sojourn time, one way in the particular queue, as per 
>> CoDel,
>> > rather
>> > > than anything TCP-related.  Clearance rate is fairly simply 
>> related to
>> > > sojourn time, of course, given enough integration time for the 
>> statistics
>> > > to converge.
>> > >
>> > >
>> > > On 2 December 2013 02:57, Detlef Bosau <detlef.bosau at web.de> 
>> wrote:
>> > >
>> > >> Am 01.12.2013 06:05, schrieb Andrew Mcgregor:
>> > >>> The actual clearance rate from the queue (or the sojourn 
>> time), if that
>> > >>> matters for your AQM scheme.  That way you are not assuming a 
>> known
>> > line
>> > >>> rate.
>> > >> Clearance rate or sojourn time?
>> > >>
>> > >> Clearance rate may apply for a packet delivery rate. From a TCP 
>> point of
>> > >> view, the sojourn time is the difference between the arrival of 
>> the
>> > >> according ACK and the time a data packet left the sender.
>> > >>
>> > >> So you omit any recovery latency.
>> > >>
>> > >>
>> > >>
>> > >>> On 30 November 2013 00:13, Detlef Bosau <detlef.bosau at web.de> 
>> wrote:
>> > >>>
>> > >>>>  Am 29.11.2013 00:24, schrieb Andrew Mcgregor:
>> > >>>>
>> > >>>> In which case... measure, don't assume.  Served us well for 
>> 802.11
>> > >>>> modulation selection, I don't see why it shouldn't work for 
>> AQM.
>> > >>>>
>> > >>>>
>> > >>>> What do you want to measure?
>> > >>>>
>> > >>>
>> > >>
>> > >> --
>> > >> 
>> ------------------------------------------------------------------
>> > >> Detlef Bosau
>> > >> Galileistraße 30
>> > >> 70565 Stuttgart                            Tel.:   +49 711 
>> 5208031
>> > >>                                            mobile: +49 172 
>> 6819937
>> > >>                                            skype:     
>> detlef.bosau
>> > >>                                            ICQ:          
>> 566129673
>> > >> detlef.bosau at web.de                    
>> http://www.detlef-bosau.de
>> >
>> > >>
>> > >>
>> > >
>> >
>> >
>> > --
>> > ------------------------------------------------------------------
>> > Detlef Bosau
>> > Galileistraße 30
>> > 70565 Stuttgart                            Tel.:   +49 711 5208031
>> >                                            mobile: +49 172 6819937
>> >                                            skype:     detlef.bosau
>> >                                            ICQ:          566129673
>> > detlef.bosau at web.de                    http://www.detlef-bosau.de
>> >
>> >
>> >
>> >
>> > --
>> > Andrew McGregor | SRE | andrewmcgr at google.com | +61 4 8143 7128
>> >
>> >
>> >
>>
>>
>> --
>> Andrew McGregor | SRE | andrewmcgr at google.com | +61 4 8143 7128

More information about the end2end-interest mailing list