From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-13-ewr.dyndns.com (mxout-113-ewr.mailhop.org [216.146.33.113]) by lists.bufferbloat.net (Postfix) with ESMTP id 9F7492E0271 for ; Tue, 15 Mar 2011 07:49:32 -0700 (PDT) Received: from scan-12-ewr.mailhop.org (scan-12-ewr.local [10.0.141.230]) by mail-13-ewr.dyndns.com (Postfix) with ESMTP id 8AD21A4B1B3 for ; Tue, 15 Mar 2011 14:49:31 +0000 (UTC) X-Spam-Score: -1.0 () X-Mail-Handler: MailHop by DynDNS X-Originating-IP: 209.85.161.43 Received: from mail-fx0-f43.google.com (mail-fx0-f43.google.com [209.85.161.43]) by mail-13-ewr.dyndns.com (Postfix) with ESMTP id 0037FA4B1A4 for ; Tue, 15 Mar 2011 14:49:30 +0000 (UTC) Received: by fxm3 with SMTP id 3so788577fxm.16 for ; Tue, 15 Mar 2011 07:49:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=Z+LkGiyBcp7CfUTNvBV4Yn0yeto+nMZGbnTA9vGGEYM=; b=WCb2W0tJwVCIhN80CjJi9fY3I1QqqJAS7AM8qhdh037yQu60tNobx6NtTi+P1PI1ys v1CWM2+ydE2Z0IKZjjTsNKL1iSg5DqCJMK7xo5Kz2HRWJvrWLqtaRp/oHepFvCqokwZC vmqEXEZzf0GnocKYo9EOLYZA1Se7V4uT2k0Jc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; b=V6xUi7AtKhfPnotFvbkuZpsQK34527gqXZ/7l+xeITHdgcLGBMjLbktjXlGHBK5u/I 5qSflPKabT5QU3zOLoVn+IE59ZDFAE2ZYXhgEAk1BfFBEYI/DDuKvjnx2pJPziyORK1+ fE6Ok7M6jreoJ6n3INhF5nq/xYnSF3VZoJBMs= MIME-Version: 1.0 Received: by 10.223.97.196 with SMTP id m4mr152489fan.105.1300200023250; Tue, 15 Mar 2011 07:40:23 -0700 (PDT) Sender: gettysjim@gmail.com Received: by 10.223.71.201 with HTTP; Tue, 15 Mar 2011 07:40:23 -0700 (PDT) In-Reply-To: <4D7F4121.40307@freedesktop.org> References: <4D7F4121.40307@freedesktop.org> Date: Tue, 15 Mar 2011 10:40:23 -0400 X-Google-Sender-Auth: o0wkFNvyDRQAcpH1xgrLw9NmrYI Message-ID: From: Jim Gettys To: bloat@lists.bufferbloat.net Content-Type: multipart/alternative; boundary=001517491d5485d7d0049e866835 Subject: Re: [Bloat] Random idea in reaction to all the discussion of TCP flavours - timestamps? X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 14:49:33 -0000 --001517491d5485d7d0049e866835 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 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 =95 Queue length is meaningless (but long term min can be useful). =95 Try have at least a bandwidth*delay of buffer. =95 Don=92t let it stay full. =95 .... 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 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 d= o > with improvements in algorithms. I'm not trying to discourage work on th= is > 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 oft= en > a very slow process. > 2) suffering from this bloat is due to the lack of signalling congesti= on > 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 sufferin= g. > It won't get us to a fundamentally different place, but only to marginal= ly > better places in terms of bufferbloating. > > The fundamental question, therefore, is how we start marking traffic duri= ng > periods when the buffers fill (either by packet drop or by ECN), to provi= de > 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 stamp= s > in them (the TCP timestamps option). > > Here's the off the wall idea. The buffers we observe are often many time= s > (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 > --001517491d5485d7d0049e866835 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I've just been re-reading Van's "A Rant on Queues", found= at:=A0http://pollere.n= et/Pdfdocs/QrantJul06.pdf=A0and am struck by a few observations in part= icular 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): "= ;=A0Three minor (and completely standard)=A0variations in protocol implemen= tation give=A0three wildly different average queue lengths.=A0I.e., the ave= rage queue length=A0contains no information=A0about demand or= load." =A0

This sends me thinking in interesting directions... Fir= st, to stop focusing on the current length of the queues as having any usef= ul information. =A0It doesn't. =A0Any buffer (or delay) in the system w= ill translate to window opening, and apps attempting to fill them. =A0We go= tta keep the queue length down.

Slide 32 states:
Suggestions
=
=95 Queue length is meaningless (bu= t long term=A0min can be useful).
=95 Try have at least a bandwidth*delay of =A0buffer.
=
=95 Don=92t let it stay full.
=95 ....=

Ok, I am struck by the first sugges= tion: we can in fact monitor the long term minimum time, whether by using T= CP 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. =A0We reall= y want to cause the buffer to empty.

There is an i= nteresting question about what "long term minimum" means here...<= /div>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 - Jim


On Tue, Mar 15, 2011 at 6:36 AM, = Jim Gettys <jg@f= reedesktop.org> wrote:
I've been watching all the discussion o= f different TCP flavours with a certain amount of disquiet; this is not bec= ause I think working on improvements to TCP are bad; in fact, it is clear f= or wireless we could do with improvements in algorithms. =A0I'm not try= ing to discourage work on this topic.

My disquiet is otherwise; it is:
=A0 =A00) the buffers can be filled by any traffic, not necessarily your o= wn (in fact, often that of others), so improving your behaviour, while admi= rable, doesn't mean you or others sharing any piece of your won't s= uffer.
=A0 =A01) the bloated buffers are already all over, and updating hosts is = often a very slow process.
=A0 =A02) suffering from this bloat is due to the lack of signalling conge= stion to congestion avoiding protocols.

OK, what does this mean? =A0it means not that we should abandon improving T= CP; but that doing so won't fundamentally eliminate bufferbloat sufferi= ng. =A0It 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 provid= e 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 mo= dern Linux (and I presume other) operating systems had time stamps in them = (the TCP timestamps option).

Here's the off the wall idea. =A0The 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 monitorin= g the timestamps that may already be present in the traffic (and knowing wh= at "sane" RTT's are) that we can start marking traffic in tim= e prevent the worst effects of bloating buffers?
=A0 =A0 =A0 =A0 =A0 =A0- Jim



_______________________________________________
Bloat mailing list
Bloat@list= s.bufferbloat.net
= https://lists.bufferbloat.net/listinfo/bloat

--001517491d5485d7d0049e866835--