From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 1152921F304 for ; Wed, 21 May 2014 10:53:31 -0700 (PDT) Received: by mail-wi0-f171.google.com with SMTP id cc10so5442089wib.16 for ; Wed, 21 May 2014 10:53:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=rRsXculne5BNkqVbl9NOuWjQwd8+Nfpv2ayWSLCaDCs=; b=X8X+/hdpugBCFnsUlnE58jlKKl4Fl1J8E1EZl1FMtR8cCpXccaYlOe4qMqOXKuWJam pF39aPXQsv2Bt85EeyACQXtFLEVAufpxArNJ5ikLZQjsAzObql5Jk7qT9WyA2HZu83P2 BMqYMoK+qSmgVGTlhw/sPv5JkTiWGHvBXnQJvMh9gJFjHgE9Eba9yD+zqM6v/1arEdtG AZxABgYPOsoZ/3Q4JpnNmNVYLbA0g4k8epEsK3MwGAHO/fk5QgYdU3WiJ5SPJAo29u+u 6HFABWGPvtLe5jnaSYJDCS6DQ2ZowPVx/4Zjw3XjQ9+s+ZFbjzGXLG2/EFKhGQ5X0Amp X2kQ== MIME-Version: 1.0 X-Received: by 10.180.206.132 with SMTP id lo4mr3139317wic.46.1400694809716; Wed, 21 May 2014 10:53:29 -0700 (PDT) Received: by 10.216.207.82 with HTTP; Wed, 21 May 2014 10:53:29 -0700 (PDT) In-Reply-To: References: <006001cf7478$804951e0$80dbf5a0$@riepnet.com> <006b01cf74e9$c9edf190$5dc9d4b0$@com> <1400683893.25854395@apps.rackspace.com> <1400688188.27216078@apps.rackspace.com> Date: Wed, 21 May 2014 10:53:29 -0700 Message-ID: From: Dave Taht To: Jim Gettys Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Frits Riep , "cerowrt-devel@lists.bufferbloat.net" Subject: Re: [Cerowrt-devel] Ideas on how to simplify and popularize bufferbloat control for consideration. 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: Wed, 21 May 2014 17:53:32 -0000 On Wed, May 21, 2014 at 10:47 AM, Jim Gettys wrote: > > > > On Wed, May 21, 2014 at 12:03 PM, wrote: >> >> In reality we don't disagree on this: >> >> >> >> On Wednesday, May 21, 2014 11:19am, "Dave Taht" >> said: >> >> > >> >> > Well, I disagree somewhat. The downstream shaper we use works quite >> > well, until we run out of cpu at 50mbits. Testing on the ubnt edgerout= er >> > has had the inbound shaper work up a little past 100mbits. So there is >> > no need (theoretically) to upgrade the big fat head ends if your cpe i= s >> > powerful enough to do the job. It would be better if the head ends did >> > it, >> > of course.... >> > >> >> >> >> There is an advantage for the head-ends doing it, to the extent that eac= h >> edge device has no clarity about what is happening with all the other cp= e >> that are sharing that head-end. When there is bloat in the head-end even= if >> all cpe's sharing an upward path are shaping themselves to the "up to" s= peed >> the provider sells, they can go into serious congestion if the head-end >> queues can grow to 1 second or more of sustained queueing delay. My >> understanding is that head-end queues have more than that. They certain= ly >> do in LTE access networks. > > > I have measured 200ms on a 28Mbps LTE quadrant to a single station. This > was using the simplest possible test on an idle cell. Easy to see how th= at > can grow to the second range. > > Similarly, Dave Taht and I took data recently that showed a large downstr= eam > buffer at the CMTS end (line card?), IIRC, it was something like .25 > megabyte, using a UDP flooding tool. No it was twice that. The udpburst tool is coming along nicely, but still needs some analytics against the departure rate to get it right. > As always, there may be multiple different buffers lurking in these compl= ex > devices, which may only come into play when different parts of them > "bottleneck", just as we found many different buffering locations inside = of > Linux. In fact, some of these devices include Linux boxes (though I do n= ot > know if they are on the packet forwarding path or not). > > Bandwidth shaping downstream of those bottlenecks can help, but only to a > degree, and I believe primarily for "well behaved" long lived elephant > flows. Offload engines on servers and coalescing acks in various equipme= nt > makes the degree of help, particularly for transient behavior such as > opening a bunch of TCP connections simultaneously and downloading the > elements of a web page I believe are likely to put large bursts of packet= s > into these queues, causing transient poor latency. I think we'll get a b= it > of help out of the packet pacing code that recently went into Linux (for > well behaved servers) as it deploys. Thanks to Eric Dumazet for that wor= k! > Ironically, servers get updated much more frequently than these middle > boxes, as far as I can tell. > > Somehow we gotta get the bottlenecks in these devices (broadband & cellul= ar) > to behave better. Or we can take a break, and write books about how we learned to relax and stop worrying about the bloat. > - Jim > >> >> >> >> _______________________________________________ >> Cerowrt-devel mailing list >> Cerowrt-devel@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/cerowrt-devel >> > --=20 Dave T=C3=A4ht NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_= indecent.article