[e2e] Codel and Wireless

[Andrew Mcgregor]

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.


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