[e2e] Codel and Wireless

[Richard Bennett]

It seems to me that indifference to applications and link layer 
conditions is not really a productive.

On 12/16/13, 4:07 PM, Detlef Bosau wrote:
> 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
>>>>
>>>
>

-- 
Richard Bennett
Visiting Fellow, American Enterprise Institute
Center for Internet, Communications, and Technology Policy
Editor, High Tech Forum