From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from eu1sys200aog121.obsmtp.com (eu1sys200aog121.obsmtp.com [207.126.144.151]) (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 5E52021F2F4 for ; Thu, 10 Jul 2014 23:20:45 -0700 (PDT) Received: from mail.la.pnsol.com ([89.145.213.110]) (using TLSv1) by eu1sys200aob121.postini.com ([207.126.147.11]) with SMTP ID DSNKU7+COZfleqSBFeBSVZRdu6Mw5ABwsi+Z@postini.com; Fri, 11 Jul 2014 06:20:46 UTC Received: from [172.20.5.238] (helo=roam.smtp.pnsol.com) by mail.la.pnsol.com with esmtp (Exim 4.76) (envelope-from ) id 1X5UCH-0007PN-1W; Fri, 11 Jul 2014 07:20:41 +0100 Received: from [172.20.5.109] by roam.smtp.pnsol.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1X5UCG-00011T-UB; Fri, 11 Jul 2014 06:20:40 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Neil Davies In-Reply-To: Date: Fri, 11 Jul 2014 07:20:40 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <02733A4B-7736-4D2B-AC22-A50C4CFA93AB@pnsol.com> References: To: Aaron Wood X-Mailer: Apple Mail (2.1878.6) 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: Fri, 11 Jul 2014 06:20:47 -0000 Aaron We did the analysis and optimisation issue with CERN about 10 years ago. = The ATLAS team has the answers.=20 Your friend needs to investigate the pattern of the packet loss, not = just its rate [dynamics of queues is an interesting issue, INRIA tech = reports are a good start]. Are they sharing this bandwidth (i.e how = stationary are the data transport properties). All that helps you work = out the optimal window size (probably just below the delay bandwidth = product for the link). Making a single TCP session saturate such links = is always hard, as for a handful - much easier - as long as they don't = create their own self-syncing DOS attack [at the key = constrained/variable resource point on the path]. Neil On 8 Jul 2014, at 05:10, Aaron Wood wrote: > List, >=20 > 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. >=20 > 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). >=20 > And suddenly the "every packet is precious" mode of thought becomes = crystal clear. >=20 > Clearly they are trying to solve different problems, yet they do have = congestion events, when new flows are added to the network. >=20 > 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. >=20 > 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. >=20 > Thanks, > Aaron > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat