[e2e] What are the shared resources? Re: Codel and Wireless

[Detlef Bosau]

In my opinion, the problem is located in a completely different place -
and in my opinion, we should think about solving it eventually.

The whole TCP congestion control issue, CoDel, AQM etc. are parts of
which, is basically a matter of resource sharing.

Does anyone contradict?

O.k., so we can fix this.

The relevant question is however not only, HOW this resources should be
shared, the question is WHAT the shared resources are!

Since Van Jacobsons paper from 1989, the shared resource is a "latency
throughput product", sometimes even called
(wrongly) "latency bandwidth product". From its physical dimension this
product is a "capacity", regardless, whether there may be actually
several packets on the line at the same time or not (WiFi, CSMA: Only
one packet at a time is possible) or whether the "capacity" is used by
packets and retransmitted data (mobile wireless networks), whathever the
resources are, they are "made" into a "generic resource" "latency
bandwidth product" - which is basically an artifact.

Nevertheless, this artifact is shared.

To my understanding, this abstraction had its justification in the late
80s, where the Internet was basically made up by a number of X.25 lines.

However, I'm absolutely not convinced, that this model holds for the
current structure of computer networks.

Hence, our problem is that we share and manage a "resource" which
actually does not exist but is an (IMHO inappropriate) "generic model"
for what's going on in reality.

Detlef

Am 17.12.2013 00:03, schrieb 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
>>>
>>
>>
>


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