[e2e] A Cute Story. Or: How to talk completely at cross purposes. Re: [ih] When was Go Back N adopted by TCP

[Detlef Bosau]

Am 04.06.2014 10:59, schrieb Jon Crowcroft:
> I dont think there's anything wrong here,

"wrong" wouldn't be an adequate word.  I think, we have different goals
here.

> but maybe a note on buffer bloat is in order:-
>
> alongside the feedback/AIMD and ack clocking mechanisms for tcp, there
> was a long discussion on right sizing buffers in the net - since AIMD
> naively applied led to the sawtooth rate behaviour in TCP, a back of
> envelope calculation
                                                                                                         
^^^^^^^^^^^^^^^^^^^^^very appropriate for a physicist :-)
Even Einstein did so :-)

> led to the notion that the bottleneck had to have a buffer to cope
> with the peak, which at worst case would be bandwidth*delay product

and exactly this might be a problem. What is the "delay" then? The more
buffer space you introduce in the path, the greater the delay, and hence
the product, will be....


> worth of packets (basically 3/2 times the mean rate) so that when 1
> more packet was sent at that rate, one loss would be incurred
> triggering the MD part of AIMD once every ln(W) worth of RTTs...[al
> this is academic in reality for lots of reasons, including the various
> other triggers like dupacks and the fact that this case is a corner
> one - since usually there are lots of flows multiplexed at the
> bottleneck(s) and multiple bottlenecks, so the appropriate buffer siz
> could be way smaller - and of course, any one running a virtual queue
> and rate estimater (i.e. AQM a la codel etc) and especially ding ECN
> rather than loss baed feedback can avoid all this rediculsous
> provisioning of packet memory all ov er the net
>

My concern is that I doubt, that this calculation should be done for the
"whole path end to end".  And of course, you will perhaps provide
sufficient buffer that the links will work at full load. Hence, the
delay will vary from propagation and serialization delays only (empty
queues) and ./. + queueing delays. Extremely rough-

> but alas, the rule of thumb for a corner case became dogma for a lot
> of router vendors for way too long to get it disestablished....


what doesn't forbid to ask questions ;-)


>
> and many of the bottlenecks today are near the edge, and more common
> than not, probably in the interface between cellular data and
> backhaul, where, as you say, thee radio link may not exhibit any kind
> of stationary capacity at all etc etc

When I got the insight of non stationary radio links fourteen years ago,
I certainly would have less grey hairs than today ;-)

>

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