From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from bifrost.lang.hm (mail.lang.hm [64.81.33.126]) (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 ACC4F21F231 for ; Mon, 7 Jul 2014 21:38:56 -0700 (PDT) Received: from asgard.lang.hm (asgard.lang.hm [10.0.0.100]) by bifrost.lang.hm (8.13.4/8.13.4/Debian-3) with ESMTP id s684csMY023722; Mon, 7 Jul 2014 21:38:54 -0700 Date: Mon, 7 Jul 2014 21:38:54 -0700 (PDT) From: David Lang X-X-Sender: dlang@asgard.lang.hm To: Aaron Wood In-Reply-To: Message-ID: References: User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: MULTIPART/Mixed; BOUNDARY="===============0607982645782392299==" Cc: bloat Subject: Re: [Bloat] fq_codel, high bandwidth, and delays 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, 08 Jul 2014 04:38:56 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --===============0607982645782392299== Content-Type: TEXT/Plain; format=flowed; charset=US-ASCII On Mon, 7 Jul 2014, Aaron Wood wrote: > > In talking with a friend over the weekend that moves data around for the > national labs (on links at rates like 10Gbps), we ended up having a rather > interesting discussion about just how radically different the problem > spaces are vs. what he's seen in the bufferbloat community. > > They have few flows, long lived, and are trying to push >1Gbps per flow, > across the continent (or from Europe to the US), with inherent delays on > the order of 100ms. TCP under these conditions is, from his reports, > incredibly fragile, where even a tiny packet error rate stops TCP for > saturating the link (since it can't tell the difference between congestion > and a non-congestion-related dropped packet). > > And suddenly the "every packet is precious" mode of thought becomes crystal > clear. Part of the answer for them is "don't do that" :-) There are many tools around to move massive amounts of data through multiple parallel TCP connections so that if one connection gets a lost packet, it doesn't kill the entire flow, only the one connection slows down (if it's true congestion, then all the flows will be slowed) David Lang > Clearly they are trying to solve different problems, yet they do have > congestion events, when new flows are added to the network. > > Has anyone used fq_codel (or it's friends) in scenarios like this? fq is > fairly new (2 years?) and I can't find much about it and high bandwidth > links in my searches. > > Given that their problems aren't those that fq is trying to solve, I > wouldn't expect it, but curious to see if anyone has any research on it. > > Thanks, > Aaron > --===============0607982645782392299== Content-Type: TEXT/PLAIN; CHARSET=us-ascii Content-ID: Content-Description: Content-Disposition: INLINE _______________________________________________ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat --===============0607982645782392299==--