[e2e] Codel and Wireless
detlef.bosau at web.de
Mon Dec 16 16:07:07 PST 2013
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
> 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
>>>> else. The code deserves really close study to understand what is
>>>> going on there, because there is a very interesting contribution in
>>>> of heuristically measuring whether flows are building queue in the
>>>> not. Empirically, this works really well on user access links,
>>>> 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
>>> 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
>>> the bottleneck) or something more sophisticated?
70565 Stuttgart Tel.: +49 711 5208031
mobile: +49 172 6819937
detlef.bosau at web.de http://www.detlef-bosau.de
More information about the end2end-interest