From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-31-ewr.dyndns.com (mxout-044-ewr.mailhop.org [216.146.33.44]) by lists.bufferbloat.net (Postfix) with ESMTP id DE5852E0392 for ; Tue, 15 Mar 2011 11:14:48 -0700 (PDT) Received: from scan-32-ewr.mailhop.org (scan-32-ewr.local [10.0.141.238]) by mail-31-ewr.dyndns.com (Postfix) with ESMTP id 13C936F862F for ; Tue, 15 Mar 2011 18:14:48 +0000 (UTC) X-Spam-Score: -4.0 (----) X-Mail-Handler: MailHop by DynDNS X-Originating-IP: 15.201.24.18 Received: from g4t0015.houston.hp.com (g4t0015.houston.hp.com [15.201.24.18]) by mail-31-ewr.dyndns.com (Postfix) with ESMTP id C783B6F8496 for ; Tue, 15 Mar 2011 18:14:43 +0000 (UTC) Received: from g4t0009.houston.hp.com (g4t0009.houston.hp.com [16.234.32.26]) by g4t0015.houston.hp.com (Postfix) with ESMTP id 73F57864E; Tue, 15 Mar 2011 18:14:43 +0000 (UTC) Received: from [16.89.244.213] (tardy.cup.hp.com [16.89.244.213]) by g4t0009.houston.hp.com (Postfix) with ESMTP id 2DE6FC189; Tue, 15 Mar 2011 18:14:43 +0000 (UTC) From: Rick Jones To: Don Marti In-Reply-To: <20110315175942.GA10064@goldfish> References: <4D7F4121.40307@freedesktop.org> <20110315175942.GA10064@goldfish> Content-Type: text/plain; charset="UTF-8" Date: Tue, 15 Mar 2011 11:14:37 -0700 Message-ID: <1300212877.2087.2155.camel@tardy> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit Cc: bloat@lists.bufferbloat.net 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 Reply-To: rick.jones2@hp.com 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 18:14:49 -0000 On Tue, 2011-03-15 at 10:59 -0700, Don Marti wrote: > begin Jonathan Morton quotation of Tue, Mar 15, 2011 at 06:47:17PM +0200: > > On 15 Mar, 2011, at 4:40 pm, Jim Gettys wrote: > > > > > There is an interesting question about what "long term minimum" means here... > > > > VJ does expand on that in "RED in a different light". He means that the relevant measure of queue length is to take the minimum value over some interval of time, say 100ms or 1-2 RTTs, whichever is longer. The average queue length is irrelevant. The nRED algorithm in that paper proposes a method of doing that. > > It seems like a host ought to be able to track the > dwell time of packets in its own buffer(s), and drop > anything that it held onto too long. > > Timestamp every packet going into the buffer, and > independently of any QoS work, check if a packet is > "stale" on its way out, and if so, drop it instead of > sending it. Is this in use anywhere? Haven't seen > it in the literature I've read linked to from Jim's > blog and this list. Are there any NICs setup to allow (efficient) removal of packets from the transmit queue (the one known to the NIC) once they have become known to the NIC? I'm not a driver writer (I've only complained to them that their drivers were using too much CPU :), but what little I've seen suggests that the programming models of most (all?) NICs are such that they assume the producer index only ever increases (modulo the queue size)... Or put another way, the host giveth, but only the NIC taketh away. rick jones