From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) (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 3FBA221F246; Tue, 29 Apr 2014 10:02:10 -0700 (PDT) Received: by mail-wg0-f47.google.com with SMTP id n12so523274wgh.30 for ; Tue, 29 Apr 2014 10:02:08 -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=d0L6SFr7u+Agobug1t9QyILuZ4vOMA66GeDi/9P3t3Y=; b=KV/rjNklSTgxwYjx+me07dTTxzGyAmi6+FdnXmaJOl4QK289xx7J6lvmYPRjib8tG8 xCd0iYFtAc6jmF/tkyKu7hobU5U6lJf577YqH50lWnT9h0uik9tvKQuzuBWmb9a0/Qr9 GCNcs8OVe9uj2R3Is1oHzZSjrJJbiOMTPKf3mYzpOORx0qLu42b05gYSGNg6s4Ao59ph GYJm9I/uVni1cgnLRpH8xPibu1ixWS6c4wIDLZv0QBJz7z9ITGOYNsuvcz9MZuLRSkZN hI0n7VoqodptIiIS4JoCyd1qZHuJqxSQExue6kg/JuYAE4iKHW0buBogdMKb5oDFuUz1 tXUg== MIME-Version: 1.0 X-Received: by 10.194.63.196 with SMTP id i4mr543351wjs.50.1398790928290; Tue, 29 Apr 2014 10:02:08 -0700 (PDT) Received: by 10.216.207.82 with HTTP; Tue, 29 Apr 2014 10:02:08 -0700 (PDT) In-Reply-To: References: <4130D000-FE28-4A5E-B824-3371C1602472@cisco.com> Date: Tue, 29 Apr 2014 10:02:08 -0700 Message-ID: From: Dave Taht To: Jim Gettys Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: bloat , "aqm@ietf.org" , "cerowrt-devel@lists.bufferbloat.net" Subject: Re: [Bloat] [aqm] the side effects of 330ms lag in the real world 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, 29 Apr 2014 17:02:11 -0000 On Tue, Apr 29, 2014 at 9:44 AM, Jim Gettys wrote: > > > > On Tue, Apr 29, 2014 at 3:56 AM, Mikael Abrahamsson > wrote: >> >> On Tue, 29 Apr 2014, Fred Baker (fred) wrote: >> >>> Well, we could discuss international communications. I happen to be at >>> Infocom in Toronto, VPN=E2=80=99d into Cisco San Jose, and did a ping t= o you: >> >> >> Yes, but as soon as you hit the long distance network the latency is the >> same regardless of access method. So while I agree that understanding th= e >> effect of latency is important, it's no longer a meaningful way of selli= ng >> fiber access. If your last-mile is fiber instead of ADSL2+ won't improve >> your long distance latency. > > > FIOS bufferbloat is a problem too. > > Measured bufferbloat, symmetric 25/25 service in New Jersey at my inlaw's > house is 200ms (on the ethernet port of the Actiontec router provided by > Verizon). So latency under load is the usual problem. ESR's link, before and after the cerowrt SQM treatment: https://www.bufferbloat.net/projects/codel/wiki/RRUL_Rogues_Gallery#Verizon= -FIOS-Testing-at-25Mbit-up-and-25Mbit-down > Why would you think the GPON guys are any better in principle than cable = or > DSL? Cable and DSL may be somewhat worse, just because it is older and > downward compatibility means that new modems on low bandwidth tiers are e= ven > more grossly over buffered. Well, buffering on the DSLAM or CMTS needs to be more actively managed. Fixed limits are much like conventional policing, always either too large or too small to handle sustained or bursty traffic respectively. I have been fiddling with Tim Shepard's "udpburst" tool as a quick means of measuring head end buffering, even with fq_codel present on the inbound. (It's not suitable for open internet use as yet, but code in progress can be had or enhanced at https://github.com/dtaht/isochronous ). I just added ecn and tos setting support to it. server: ./udpburst -S -E -D 32 # Server mode, enable ECN marking, set dscp to 0x20 (CS1) client: This is from a 22Mbit down CMTS d@nuc:~/git/isochronous$ ./udpburst -f 149.20.63.30 -E -C -d -n 400 -s 1400 1400 bytes -- received 382 of 400 -- 365 consecutive 0 ooo 0 dups 2 ect ........................................................................ ........................................................................ ........................................................................ ........................................................................ ........................................................................ .... .. . ... . ... . .. .. . . 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 3 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 3 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 or roughly 512k of buffering. A DSL link (6400 down) d@puck:~/git/isochronous$ ./udpburst -f snapon.lab.bufferbloat.net -n 100 -C -d -s 1000 1000 bytes -- received 71 of 100 -- 71 consecutive 0 ooo 0 dups 0 ect ...................................................................... 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 or roughly 64k worth of buffering. Interestingly the bandwidth disparity be= tween the server (gigE in isc.org's co-lo), is so great that fq_codel can't kick in before the 64k dslam buffer is overrun. > You can look at the netalyzr scatter plots in > http://gettys.wordpress.com/2010/12/06/whose-house-is-of-glasse-must-not-= throw-stones-at-another/ > > Now, if someone gives me real fiber to the home, with a real switch fabri= c > upstream, rather than gpon life might be somewhat better (if the switches > aren't themselves overbuffered.... But so far, it isn't. > - Jim > > - Jim > > - Jim > >> >> >> -- >> Mikael Abrahamsson email: swmike@swm.pp.se >> >> _______________________________________________ >> Bloat mailing list >> Bloat@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/bloat >> > > > _______________________________________________ > aqm mailing list > aqm@ietf.org > https://www.ietf.org/mailman/listinfo/aqm > --=20 Dave T=C3=A4ht NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_= indecent.article