I've just been re-reading Van's "A Rant on Queues", found at: <meta http-equiv="content-type" content="text/html; charset=utf-8"><a href="http://pollere.net/Pdfdocs/QrantJul06.pdf">http://pollere.net/Pdfdocs/QrantJul06.pdf</a> and am struck by a few observations in particular there.<div>
<br></div><div>Slide 14 is useful to focus the mind on the problem we face with home routers (or many of these individual boxes in the network): " Three minor (and completely standard) variations in protocol implementation give three wildly different average queue lengths. I.e., the average queue length contains <u><b>no</b></u> information about demand or load." </div>
<div><br></div><div>This sends me thinking in interesting directions... First, to stop focusing on the current length of the queues as having any useful information. It doesn't. Any buffer (or delay) in the system will translate to window opening, and apps attempting to fill them. We gotta keep the queue length down.</div>
<div><br></div><div>Slide 32 states:</div><div><div>Suggestions</div></div><blockquote class="webkit-indent-blockquote" style="margin: 0 0 0 40px; border: none; padding: 0px;"><div><div>• Queue length is meaningless (but long term min can be useful).</div>
</div><div><div>• Try have at least a bandwidth*delay of buffer.</div></div><div><div>• Don’t let it stay full.</div></div><div><div>• ....</div></div><div><br></div></blockquote>Ok, I am struck by the first suggestion: we can in fact monitor the long term minimum time, whether by using TCP timestamps, or other hackish measures.<div>
<br></div><div>Whenever packets are delayed by significantly more than this minimum time, we know we are congested, and should be marking. We really want to cause the buffer to empty.</div><div><br></div><div>There is an interesting question about what "long term minimum" means here...</div>
<div> - Jim</div><div><br><div><br><div class="gmail_quote">On Tue, Mar 15, 2011 at 6:36 AM, Jim Gettys <span dir="ltr"><<a href="mailto:jg@freedesktop.org">jg@freedesktop.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">I've been watching all the discussion of different TCP flavours with a certain amount of disquiet; this is not because I think working on improvements to TCP are bad; in fact, it is clear for wireless we could do with improvements in algorithms. I'm not trying to discourage work on this topic.<br>
<br>
My disquiet is otherwise; it is:<br>
0) the buffers can be filled by any traffic, not necessarily your own (in fact, often that of others), so improving your behaviour, while admirable, doesn't mean you or others sharing any piece of your won't suffer.<br>
1) the bloated buffers are already all over, and updating hosts is often a very slow process.<br>
2) suffering from this bloat is due to the lack of signalling congestion to congestion avoiding protocols.<br>
<br>
OK, what does this mean? it means not that we should abandon improving TCP; but that doing so won't fundamentally eliminate bufferbloat suffering. It won't get us to a fundamentally different place, but only to marginally better places in terms of bufferbloating.<br>
<br>
The fundamental question, therefore, is how we start marking traffic during periods when the buffers fill (either by packet drop or by ECN), to provide the missing feedback in congestion avoiding protocol's servo system. No matter what flavour of protocol involved, they will then back off.<br>
<br>
Back last summer, to my surprise, when I asked Van Jacobson about my traces, he said all the required proof was already present in my traces, since modern Linux (and I presume other) operating systems had time stamps in them (the TCP timestamps option).<br>
<br>
Here's the off the wall idea. The buffers we observe are often many times (orders of magnitude) larger than any rational RTT.<br>
<br>
So the question I have is whether there is some technique whereby monitoring the timestamps that may already be present in the traffic (and knowing what "sane" RTT's are) that we can start marking traffic in time prevent the worst effects of bloating buffers?<br>
- Jim<br>
<br>
<br>
<br>
_______________________________________________<br>
Bloat mailing list<br>
<a href="mailto:Bloat@lists.bufferbloat.net" target="_blank">Bloat@lists.bufferbloat.net</a><br>
<a href="https://lists.bufferbloat.net/listinfo/bloat" target="_blank">https://lists.bufferbloat.net/listinfo/bloat</a><br>
</blockquote></div><br></div></div>