From detlef.bosau at web.de Tue Jul 29 04:02:18 2014 From: detlef.bosau at web.de (Detlef Bosau) Date: Tue, 29 Jul 2014 13:02:18 +0200 Subject: [e2e] Once again buffer bloat and CC. Re: A Cute Story. Or: How to talk completely at cross purposes. Re: [ih] When was Go Back N adopted by TCP In-Reply-To: References: <20140519150259.35C1E28E137@aland.bbn.com> <537B35D0.9040400@web.de> <538DC307.90101@web.de> Message-ID: <53D77F3A.5020100@web.de> Am 04.06.2014 um 02:01 schrieb Andrew Mcgregor: > Bufferbloat definitely does impair performance, by slowing down feedback it > increases the variance of the system workload, which inevitably causes > either packet drops because there is a finite buffer limit in reach, or by > causing such large delays that retransmission timers fire for packets that > are still in flight. In either case, the system is doing excess work. > I thought quite a bit about that during the last weeks and sometimes I think, we're mixing up cause and effect. And we basically rely upon assumptions which may be put in question. IIRC, David Reed pointed out some weeks ago what he defines as "bufferbloat". Simply put: A packet conveyed in a network spends most of its sojourn time in queues. Now the problem is that we cannot determine a packet's "queuing time" a posteriori. So, sometimes we have criteria for buffer bloat, e.g. Coddle, where buffer bloat means "a packet resides in the local router queue for more than 100 ms". (Whether 100 ms is defined by experience or by divine inspiration is still opaque to me, it will certainly become clear when this contstant is assigned a name and the Turing Award is awarded.) According to Dave's definition it is no way clear, whether a flow experiences buffer bloat from this single queueing time. When a packet experiences 5 seconds of sojourn time - and the 100 ms in the local router queue are its only queueing delay, anything is fine. If the 0,1000000000000000000000000000000000000000001 seconds soujourn time consists of 100 ms queueing delay "and a little rest", this would be unsatisfactory. In other words: Buffer bloat is not a phenomenon for a single flow - but a symptom of wrong system design. Now, there are quite some rules of thumb how buffers should be designed that buffer bloat is avoided - and all of these miss the problem. The problem is: Queues are utilized. And when congestion and resource control are handled by feedback in a way that a system which does not drop packets is not fully utilized, queues WILL BE FULLY UTILIZED, because we offer that much load to a system that it eventually drops packets. That's basically the same af if you don't know the size of your fridge - and you fill in butter and milk and cheese - until the whole mess becomes lively and walks out. And then you throw away the whole mess, clean your fridge - and restart the same procedure from the beginning. (We call this "probing". In the context of a fridge: Mould cheese probing.) My basic question is: Can we avoid probing? Wouldn't it be preferable to probing to assign known resources by proper scheduling instead? Isn't probing the very problem? Hence, CUTE and VJCC basically introduce the problem which they pretend to solve? WRT buffer bloat: When we don't offer inappropriate load to a network and all packets could be served in reasonable time, there wouldn't be any buffer bloat at all. From detlef.bosau at web.de Tue Jul 29 04:10:50 2014 From: detlef.bosau at web.de (Detlef Bosau) Date: Tue, 29 Jul 2014 13:10:50 +0200 Subject: [e2e] a remark In-Reply-To: <53D77F3A.5020100@web.de> References: <20140519150259.35C1E28E137@aland.bbn.com> <537B35D0.9040400@web.de> <538DC307.90101@web.de> <53D77F3A.5020100@web.de> Message-ID: <53D7813A.3000504@web.de> The precise analogy for buffer bloat in operating systems is "thrashing". Hence, a process' sojourn time in a system is spend mostly by swapping in or swapping out its pages. So the question is the same: How to we avoid thrashing in operating systems? In case of memory leaks, I have a look at the output of "top" and I feel free to issue a "kill -9" to the "one weird process" - as long as I'm able to do so. However, better ideas exist ;-) -- ------------------------------------------------------------------ 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