From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id 2FBE121F1FC for ; Thu, 4 Jul 2013 08:48:26 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 8446C9C; Thu, 4 Jul 2013 17:48:23 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 7A8B29A; Thu, 4 Jul 2013 17:48:23 +0200 (CEST) Date: Thu, 4 Jul 2013 17:48:23 +0200 (CEST) From: Mikael Abrahamsson To: Michael Richardson In-Reply-To: <22039.1372945874@sandelman.ca> Message-ID: References: <22039.1372945874@sandelman.ca> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: cerowrt-devel@lists.bufferbloat.net Subject: Re: [Cerowrt-devel] happy 4th! X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jul 2013 15:48:26 -0000 On Thu, 4 Jul 2013, Michael Richardson wrote: > huh? The end points might need more buffers to receive more packets (some of > which might be out of order), but the intermediate routers need nothing. > None of the bufferbloat stuff reduces the receive buffers of an end-point. I never talked about the end-points receive buffers. I was talking about intermediate routers buffering. With long-latency links, TCP traditionally sends packets at fairly big bursts sent at wirespeed of the end system, and when this burst arrives at a router doing speed conversion (1gige->1megabit/s WAN link), it will need to buffer some of this burst. This is why buffers are large on routers, because of this traditional thinking that TCP works best when routers in between never drops packets. > So, who is saying this to you, and what exactly do they think > bufferbloat is about? They say if you reduce the buffer size in routers, TCP performance on long latency paths will suffer due to packet loss and long recovery times due to the end-to-end high latency. Traditional thinking (I've had this quoted to me by several old-timers who have been involved in core router design since the 90ties) is that you need buffers who can accept 2*RTT amount of packets at the speed you're trying to send. So if we want to reduce the buffers, we need to prove that TCP goodput on a 200ms link doesn't suffer because there are now less buffers. So my suggestion is the following: When doing the tests, set up the following: [host1] - (GE/FE/E) - [fq_codel router] - [100ms adding latency router] (GE) [host2] The link between CODEL-router and the router adding latency should be 1/10 and 1/100 of the [host1] - [CODEL-router] link speed. If it can be shown that fq_codel keeps the goodput performance the same as FIFO with large buffers, then we hopefully could answer people with the concerns I mentioned before. -- Mikael Abrahamsson email: swmike@swm.pp.se