Re: [Bloat] Random idea in reaction to all the discussion of TCP flavours - timestamps?

[Jim Gettys <jg@freedesktop.org>]

[-- Attachment #1: Type: text/plain, Size: 3785 bytes --]

I've just been re-reading Van's "A Rant on Queues", found at:
http://pollere.net/Pdfdocs/QrantJul06.pdf and am struck by a few
observations in particular there.

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 *no* information about demand or load."

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.

Slide 32 states:
Suggestions

• Queue length is meaningless (but long term min can be useful).
• Try have at least a bandwidth*delay of  buffer.
• Don’t let it stay full.
• ....

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.

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.

There is an interesting question about what "long term minimum" means
here...
                            - Jim


On Tue, Mar 15, 2011 at 6:36 AM, Jim Gettys <jg@freedesktop.org> wrote:

> 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.
>
> My disquiet is otherwise; it is:
>    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.
>    1) the bloated buffers are already all over, and updating hosts is often
> a very slow process.
>    2) suffering from this bloat is due to the lack of signalling congestion
> to congestion avoiding protocols.
>
> 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.
>
> 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.
>
> 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).
>
> Here's the off the wall idea.  The buffers we observe are often many times
> (orders of magnitude) larger than any rational RTT.
>
> 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?
>            - Jim
>
>
>
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
>

[-- Attachment #2: Type: text/html, Size: 4741 bytes --]