From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-22-ewr.dyndns.com (mxout-041-ewr.mailhop.org [216.146.33.41]) by lists.bufferbloat.net (Postfix) with ESMTP id EC5642E00F5 for ; Tue, 15 Mar 2011 03:36:26 -0700 (PDT) Received: from scan-22-ewr.mailhop.org (scan-22-ewr.local [10.0.141.244]) by mail-22-ewr.dyndns.com (Postfix) with ESMTP id DBFD62F545 for ; Tue, 15 Mar 2011 10:36:24 +0000 (UTC) X-Spam-Score: 0.0 () X-Mail-Handler: MailHop by DynDNS X-Originating-IP: 76.96.27.227 Received: from qmta12.emeryville.ca.mail.comcast.net (qmta12.emeryville.ca.mail.comcast.net [76.96.27.227]) by mail-22-ewr.dyndns.com (Postfix) with ESMTP id 638282E2C7 for ; Tue, 15 Mar 2011 10:36:20 +0000 (UTC) Received: from omta15.emeryville.ca.mail.comcast.net ([76.96.30.71]) by qmta12.emeryville.ca.mail.comcast.net with comcast id KNcK1g0011Y3wxoACNcKvM; Tue, 15 Mar 2011 10:36:19 +0000 Received: from [192.168.1.119] ([98.229.99.32]) by omta15.emeryville.ca.mail.comcast.net with comcast id KNcH1g0020hvpMe8bNcJWK; Tue, 15 Mar 2011 10:36:19 +0000 Message-ID: <4D7F4121.40307@freedesktop.org> Date: Tue, 15 Mar 2011 06:36:17 -0400 From: Jim Gettys Organization: Bell Labs User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: bloat@lists.bufferbloat.net Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [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 10:36:27 -0000 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