[e2e] Codel and Wireless

[Markku Kojo]

Hi Andrew,

catching up with this thread ...

On Fri, 6 Dec 2013, Andrew Mcgregor wrote:

> I'm running a fairly standard OpenWRT QoS config, with ingress and egress
> shaping to prevent (too much) upstream queueing either in the network or in
> the modem; I get about 22Mbps symmetric performance on this particular
> setup, with reasonable latencies (I wouldn't be happy if I was FPS gaming,
> but it's fine for everything else).  I don't remember the latency numbers
> off the top of my head.  It's actually one of the better broadband
> connections available in Australia, it's just a shame about the cost.

This is clever way of making things work better over LTE.
If I understood your setup correctly, you have moved the bottleneck
(partially?) away from the LTE link by using shaping?
In my view this, however, does not provide an empirical proof that
fq_codel works fine over a LTE bottleneck. It's the shaping
(together with fq for uplink) that makes the trick. Please correct
me if I am wrong.

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. 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), quite totally hidden from your
favorite IP AQM/scheduling, 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 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.

Cheers,

/Markku


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