[e2e] Codel and Wireless

Thu Dec 5 04:11:55 PST 2013

Daniel,

as you know, GPRS allows 0.95 quantiles for 1024 byte packets up to
about 10 minutes.

And that's the annoying point in this discussion. Perhaps, we should
have a look at the standadards. At least occasionally.

Now: Can't we use GPRS then? No, or better: Obama. Yes We Can! Yes We Can!

Why?

Of course GPRS employs timeouts. However GPRS employs a radio block
protocol which logs the round trip times for radio blocks in a GPRS link.
And as you know further, GSM requires a "Timing Advance" to have all
mobiles send their data timely according to the assigned timeslot and
their is a certain timing advance for the uplink with respect to the
downlink.

(For NSA readers: Feel free to use this information for mobile location
in GSM networks, the German police does so for about 20 years now. You
are welcome to ask for information.)

Hence, at link layer GPRS can successfully work with timeouts - perhaps
not very efficiently because these timeouts perhaps are not even
dynamic, I don't know.

Nevertheless, as soon als you have at least one mobile link in the path,
the end to end delivery time is

NOT
a stationary random process and therefore the use of ARMA or EWMA
filters or what ever does

NOT
render an estimate for the process' limit pdf's expectation.

Or, put in very simple and very drastic words (and dressing myself in my
fire protection suite): The use of EWMA or RTT filters to obtain STT or
RTT values for L 3 packets in paths containing even a single mobile link is

NONSENSE.

(These filters will well provide a number. However, the numbers are of
no use, it's the classical "GIGO" system. Garbage In Garbage Out.)

Admittedly, my intention is absolutely not to focus too much on mobile
networks, because this discussion is as boaring as useless. 
For 14 years now, I see two parties: The CS guys who ignore reality and
the reality and CE and EE guys who ignore the CS guys.

I know that this sounds arrogant. However, after dealing with this
matter for 14 years know and heaving read hundreds of papers concerning
this matter, I simply dare the statement: Both, Lixia Zhang and Raj Jain
were correct, when they stated (independently) that timers (and they
discussed e2e timers as used in TCP) simply don't work, so I don't make
a new claim but simply confirm what is known to the community for about
25 years.

And particularly for mobile networks, I talk to colleagues and after the
third mug of coffee the say: I know that it doesn't work, nevertheless I
do it that way.

And perhaps there is some additional fingerpointing to bad
implementations of GPRS or some lousy excuses, however, and please allow
me this word at least for this one moment: Bullshit is Bullshit and
Bullshit remains Bullshit.

Particularly the hope for a "worst case RTT" in wireless networks is
simply ridiculous. And of no interest at all.
Although I personally use to think networks "bottom up", networks are
supposed to be designed top down: The network serves the user, it must
not be the other way round. So it is simply not the question what a
worst case RTT in a network could be - the only question is: What is the
user's requirement?

And sometimes, it requires a brave and tough and strong and wise guy to
tell a user: I'm sorry, but I cannot fulfill your requirements. Or as
you know from the famous RFC: no matter how you push or pull, no matter
which priority your project may have - you cannot increase the speed of
light!

So, when there is at least one "killer argument" (terrible Germish, but
you certainly understand what I mean) against a strict end 2 end
attitude in TCP, this argument is called "timeouts" or "round trip
times" respectively.

Am 04.12.2013 00:10, schrieb Daniel Havey:
> On Tuesday, December 3, 2013 2:41 PM, Andrew Mcgregor
> <andrewmcgr at google.com> wrote:
> All of which is why fq_codel is so much better... because flows queue
> independently, and drops are calculated per flow (although overall
> queue size is included implicitly via the sojourn time), the RTT delay
> has far less impact.  CoDel is an ingredient of an AQM system, not a
> desirable AQM on its own.
>
> >Makes sense to me.  We need to get the worst case RTT right.  If we
> set the interval to 100ms then the user with the users with larger
> RTTs may have issues.
>
> On 4 December 2013 08:11, Daniel Havey <dhavey at yahoo.com
> <mailto:dhavey at yahoo.com>> wrote:
>
>
>
>
>
>
>     On Tuesday, December 3, 2013 12:22 PM, Detlef Bosau
>     <detlef.bosau at web.de <mailto:detlef.bosau at web.de>> wrote:
>
>     To my understanding, the "sojourn time" considered in CoDel is the
>     difference between the time when a packet/leaves /a queue and the
>     time,
>     when this packet has /arrived /at the queue. In other words: The
>     time a
>     packet spends in the queue.
>
>     When this time is unusually high, CoDel sees an imminent
>     congestion and
>     drops packets.
>
>     The problem is that CoDel makes no difference whether the "sojourn
>     time"
>     is caused by a huge number of packets in the queue, i.e.
>     congestion, or
>     by a huge delivery time resulting from corruption loss and necessary
>     retransmissions.
>
>     CoDel parameters are interval and target.  If the queue drains
>     before the interval then there shouldn't be any drops.   Also
>     there is "leverage" from Red in a Different Light.  If CoDel
>     decides to drop a packet from a flow that is in congestion
>     avoidance, fast retransmit or slow start then the window is halved
>     and the queue drains quickly.  If the flow doesn't have enough
>     data to trigger fast retransmit then that is unfortunate for that
>     user since they now have to wait an RTT for that packet, and it
>     does not drain the queue very much.
>
>
>     Hence, we have the good old loss differentiation problem. And because
>     CoDel is particularly intended for edge routers, the disaster is
>     placed
>     exactly there where it is expected to happen......8-)
>
>     Detlef
>
>     Am 01.12.2013 22:16, schrieb Andrew Mcgregor:
>     > I mean sojourn time, one way in the particular queue, as per
>     CoDel, rather
>     > than anything TCP-related.  Clearance rate is fairly simply
>     related to
>     > sojourn time, of course, given enough integration time for the
>     statistics
>     > to converge.
>     >
>     >
>     > On 2 December 2013 02:57, Detlef Bosau <detlef.bosau at web.de
>     <mailto:detlef.bosau at web.de>> wrote:
>     >
>     >> Am 01.12.2013 06:05, schrieb Andrew Mcgregor:
>     >>> The actual clearance rate from the queue (or the sojourn
>     time), if that
>     >>> matters for your AQM scheme.  That way you are not assuming a
>     known line
>     >>> rate.
>     >> Clearance rate or sojourn time?
>     >>
>     >> Clearance rate may apply for a packet delivery rate. From a TCP
>     point of
>     >> view, the sojourn time is the difference between the arrival of the
>     >> according ACK and the time a data packet left the sender.
>     >>
>     >> So you omit any recovery latency.
>     >>
>     >>
>     >>
>     >>> On 30 November 2013 00:13, Detlef Bosau <detlef.bosau at web.de
>     <mailto:detlef.bosau at web.de>> wrote:
>     >>>
>     >>>>  Am 29.11.2013 00:24, schrieb Andrew Mcgregor:
>     >>>>
>     >>>> In which case... measure, don't assume.  Served us well for
>     802.11
>     >>>> modulation selection, I don't see why it shouldn't work for AQM.
>     >>>>
>     >>>>
>     >>>> What do you want to measure?
>     >>>>
>     >>>
>     >>
>     >> --
>     >> ------------------------------------------------------------------
>     >> 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 <mailto:detlef.bosau at web.de>               
>         http://www.detlef-bosau.de <http://www.detlef-bosau.de/>
>
>     >>
>     >>
>     >
>
>
>     --
>     ------------------------------------------------------------------
>     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 <mailto:detlef.bosau at web.de>                 
>       http://www.detlef-bosau.de <http://www.detlef-bosau.de/>
>
>
>
>
> -- 
> Andrew McGregor | SRE | andrewmcgr at google.com
> <mailto:andrewmcgr at google.com> | +61 4 8143 7128
>
>

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