[e2e] Codel and Wireless

[Detlef Bosau]

Am 17.12.2013 00:03, schrieb Markku Kojo:
> It is not only fq_codel that is likely to have problems over most
> wireless technologies but any proposed AQM today has hard time to
> work properly over wireless bottleneck links like LTE, 3G, GPRS, wifi,
> satellite, etc.


Christmas time is coming :-) (I have "Holidays are coming" in mind,
however, I must not do any advertising here ;-))

Over time, I feared I were the only one to doubt AQM mechanisms over
wireless bottleneck links.


> For various reasons (some well justified some not so), these
> technologies tend to buffer significant amount of data below
> the IP layer (as Keith indicated),

The major reason is to utilize the highly volatile throughput.

And it is of major importance not to empty necessary buffers here e.g.
as a consequence of congestion handling.

> quite totally hidden from your
> favorite IP AQM/scheduling, 
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

that's exactly what makes splitting appealing in this context: Necessary
buffers and their contents are hidden from TCP congestion control and
queue management!

> i.e., without a very specific cross-layer
> implementation RED does not know the actual queue length, PIE is not
> able to correctly figure out the departure rate, and fq_codel is not
> able to calculate the correct sojourn time 


So, you understand my thoughts on this one?
> nor drop or schedule the packets from the actual heads of the queues.
> This is not to say that
> a properly working AQM/scheduling is not doable, but there is a big
> obstacle as long as we continue using such a strict layering model
> between the IP and link layer and enforce it in the implementations.

Thank you very much for posting this comment.
>
>> On 6 December 2013 11:16, Keith Winstein <keithw at mit.edu> wrote:
>>
>>> On Thu, Dec 5, 2013 at 6:22 PM, Andrew Mcgregor
>>> <andrewmcgr at google.com>wrote:
>>>
>>>> By the way, fq_codel is not a combination of SFQ and CoDel, but
>>>> something
>>>>  else.  The code deserves really close study to understand what is
>>>> really
>>>> going on there, because there is a very interesting contribution in
>>>> terms
>>>> of heuristically measuring whether flows are building queue in the
>>>> qdisc
>>>> or
>>>> not.  Empirically, this works really well on user access links,
>>>> including
>>>> LTE, by my own direct observation having run it on my home
>>>> network's LTE
>>>> link for many months now.
>>>
>>>
>>> Andrew, I'd love to hear more about how you do this. Do you run
>>> fq_codel
>>> on the uplink or somehow also on the downlink? How do you prevent
>>> the LTE
>>> modem or baseband from buffering hundreds of kilobytes inside itself
>>> -- do
>>> you use an upstream traffic shaper (to prevent the LTE link from
>>> becoming
>>> the bottleneck) or something more sophisticated?
>>>
>>> Cheers,
>>> Keith
>>>
>>
>>
>


-- 
------------------------------------------------------------------
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