From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp105.iad3a.emailsrvr.com (smtp105.iad3a.emailsrvr.com [173.203.187.105]) (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 0500321F1D6 for ; Sun, 17 May 2015 20:30:28 -0700 (PDT) Received: from smtp6.relay.iad3a.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp6.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id A438218031D; Sun, 17 May 2015 23:30:15 -0400 (EDT) Received: from app47.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp6.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 70F9E18010E; Sun, 17 May 2015 23:30:15 -0400 (EDT) X-Sender-Id: dpreed@reed.com Received: from app47.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by 0.0.0.0:25 (trex/5.4.2); Mon, 18 May 2015 03:30:15 GMT Received: from reed.com (localhost.localdomain [127.0.0.1]) by app47.wa-webapps.iad3a (Postfix) with ESMTP id 5E958380095; Sun, 17 May 2015 23:30:15 -0400 (EDT) Received: by apps.rackspace.com (Authenticated sender: dpreed@reed.com, from: dpreed@reed.com) with HTTP; Sun, 17 May 2015 23:30:15 -0400 (EDT) Date: Sun, 17 May 2015 23:30:15 -0400 (EDT) From: dpreed@reed.com To: "Simon Barber" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_20150517233015000000_45394" Importance: Normal X-Priority: 3 (Normal) X-Type: html In-Reply-To: <14d5800ec08.27f7.e972a4f4d859b00521b2b659602cb2f9@superduper.net> References: <8C015B1B-EFBA-4647-AD83-BAFDD16A4AF2@netapp.com> <14d5800ec08.27f7.e972a4f4d859b00521b2b659602cb2f9@superduper.net> X-Auth-ID: dpreed@reed.com Message-ID: <1431919815.385726792@apps.rackspace.com> X-Mailer: webmail/11.4.2-RC Cc: =?utf-8?Q?Bill_Ver_Steeg_=28versteb=29?= , "Klatsky, Carl" , cake@lists.bufferbloat.net, cerowrt-devel@lists.bufferbloat.net, bloat Subject: Re: [Cerowrt-devel] [Bloat] heisenbug: dslreports 16 flow test vs cablemodems 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: Mon, 18 May 2015 03:31:17 -0000 ------=_20150517233015000000_45394 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0AWhat's your definition of 802.11 performing well? Just curious. Maximi= zing throughput at all costs or maintaing minimal latency for multiple user= s sharing an access point?=0A=0AOf course, if all you are doing is trying t= o do point-to-point outdoor links using 802.11 gear, the issue is different= - similar to "dallying" to piggyback acks in TCP, which is great when you = have two dimensional flows, but lousy if each packet has a latency requirem= ent that is small.=0A =0ATo me this is hardly so obvious. Maximizing packet= sizes is actually counterproductive for many end-to-end requirements. But= of course for "hot rod benchmarkers" applications don't matter at all - ju= st the link performance numbers.=0A =0AOne important use of networking is m= ultiplexing multiple users. Otherwise, bufferbloat would never matter.=0A = =0AWhich is why I think actual numbers rather than "hand waving claims" mat= ter.=0A=0A=0AOn Friday, May 15, 2015 10:36am, "Simon Barber" said:=0A=0A=0A=0A=0A=0AOne question about TCP small queues (which = I don't think is a good solution to the problem). For 802.11 to be able to = perform well it needs to form maximum size aggregates. This means that it n= eeds to maintain a minimum queue size of at least 64 packets, and sometimes= more. Will TCP small queues prevent this?=0ASimon=0ASent with AquaMail for= Android=0A[ http://www.aqua-mail.com ]( http://www.aqua-mail.com )=0A=0AOn= May 15, 2015 6:44:21 AM Jim Gettys wrote:=0A=0A=0A=0A= On Fri, May 15, 2015 at 9:09 AM, Bill Ver Steeg (versteb) <[ versteb@cisco.= com ]( mailto:versteb@cisco.com )> wrote:=0ALars-=0A=0A You make some good = points. It boils down to the fact that there are several things that you ca= n measure, and they mean different things.=0A=0A Bvs=0A=0A=0A=0A=0A -----Or= iginal Message-----=0A From: Eggert, Lars [mailto:[ lars@netapp.com ]( mail= to:lars@netapp.com )]=0A Sent: Friday, May 15, 2015 8:44 AM=0A To: Bill Ver= Steeg (versteb)=0A Cc: Aaron Wood; [ cake@lists.bufferbloat.net ]( mailto:= cake@lists.bufferbloat.net ); Klatsky, Carl; [ cerowrt-devel@lists.bufferbl= oat.net ]( mailto:cerowrt-devel@lists.bufferbloat.net ); bloat=0A Subject: = Re: [Bloat] [Cerowrt-devel] heisenbug: dslreports 16 flow test vs cablemode= ms=0A=0A=0A I disagree. You can use them to establish a lower bound on the = delay an application over TCP will see, but not get an accurate estimate of= that (because socket buffers are not included in the measurement.) And you= rely on the network to not prioritize ICMP/UDP but otherwise leave it in t= he same queues.=0A=0A=E2=80=8BOn recent versions of Linux and Mac, you can= get most of the socket buffers to "go away". I forget the socket option o= ffhand.=E2=80=8B =0A=0A=E2=80=8BAnd TCP small queues in Linux means that Li= nux no longer gratuitously generates packets just to dump them into the que= ue discipline system where they will rot.=0AHow accurate this now can be is= still an interesting question: but has clearly improved the situation a lo= t over 3-4 years ago.=E2=80=8B=0A=0A=0A > If you can instrument TCP in the = kernel to make instantaneous RTT available to the application, that might w= ork. I am not sure how you would roll that out in a timely manner, though.= =0A=0A=0A=E2=80=8BWell, the sooner one starts, the sooner it gets deployed.= =E2=80=8B=0AJim_______________________________________________=0A Bloat mai= ling list=0A Bloat@lists.bufferbloat.net=0A[ https://lists.bufferbloat.net/= listinfo/bloat ]( https://lists.bufferbloat.net/listinfo/bloat )=0A=0A ------=_20150517233015000000_45394 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

What= 's your definition of 802.11 performing well?  Just curious.  Max= imizing throughput at all costs or maintaing minimal latency for multiple u= sers sharing an access point?

Of course, if all you are doing is= trying to do point-to-point outdoor links using 802.11 gear, the issue is = different - similar to "dallying" to piggyback acks in TCP, which is great = when you have two dimensional flows, but lousy if each packet has a latency= requirement that is small.

=0A

 

= =0A

To me this is hardly so obvious. Maximizing= packet sizes is actually counterproductive for many end-to-end requirement= s.  But of course for "hot rod benchmarkers" applications don't matter= at all - just the link performance numbers.

=0A

 

=0A

One important use of network= ing is multiplexing multiple users.  Otherwise, bufferbloat would neve= r matter.

=0A

 

=0A

Which is why I think actual numbers rather than "hand waving cl= aims" matter.

=0A=0A



On Friday, May 15, 201= 5 10:36am, "Simon Barber" <simon@superduper.net> said:

=0A

=0A
=0A=0A

One question about TCP small queues (which I don't think= is a good solution to the problem). For 802.11 to be able to perform well = it needs to form maximum size aggregates. This means that it needs to maint= ain a minimum queue size of at least 64 packets, and sometimes more. Will T= CP small queues prevent this?

=0A

Simon

=0A

Sent with AquaMail for Android
http://www.aqua-mail.com

=0A
=0A
=0A

On May 15, 2= 015 6:44:21 AM Jim Gettys <jg@freedesktop.org> wrote:

=0A=0A
=0A

=0A
On Fri, May 15, 2015 at 9:09= AM, Bill Ver Steeg (versteb) <versteb@cisco.com> wrote:
=0A
Lars-

You make some g= ood points. It boils down to the fact that there are several things that yo= u can measure, and they mean different things.
=
Bvs
=0A
=0A


-----Original Message----- From: Eggert, Lars [mailto:lars@neta= pp.com]
Sent: Friday, May 15, 2015 8:44 AM
To: Bill Ver Ste= eg (versteb)
Cc: Aaron Wood; cake@lists.bufferbloat.net; Klatsky, Carl; cerowrt-devel@lists.bufferbloat.net; b= loat
Subject: Re: [Bloat] [Cerowrt-devel] heisenbug: dslreports 16 fl= ow test vs cablemodems


I disagree. You can use them to es= tablish a lower bound on the delay an application over TCP will see, but no= t get an accurate estimate of that (because socket buffers are not included= in the measurement.) And you rely on the network to not prioritize ICMP/UD= P but otherwise leave it in the same queues.
=0A
=0A
= =0A
=0A
=E2=80=8BOn recent versions of  Linux and Mac, you can get m= ost of the socket buffers to "go away".  I forget the socket option of= fhand.=E2=80=8B
=0A 
=0A
=0A
=E2=80=8BAnd TCP small queues in Linux means t= hat Linux no longer gratuitously generates packets just to dump them into t= he queue discipline system where they will rot.
=0A
How accurate this now can be is still= an interesting question: but has clearly improved the situation a lot over= 3-4 years ago.=E2=80=8B
=0A
=0A
=0A
=0A

> If you can in= strument TCP in the kernel to make instantaneous RTT available to the appli= cation, that might work. I am not sure how you would roll that out in a tim= ely manner, though.

=0A
=0A
=0A
=E2=80=8BWell, the sooner on= e starts, the sooner it gets deployed.=E2=80=8B
=0A
Jim
=0A
=0A
=0A
= =0A_______________________________________________
Bloat mailing list=
Bloat@lists.bufferbloat.net
https://lists.buf= ferbloat.net/listinfo/bloat

=0A
=0A
= =0A ------=_20150517233015000000_45394--