From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from masada.superduper.net (unknown [IPv6:2001:ba8:1f1:f263::2]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id 87DE821F3F6; Fri, 15 May 2015 07:36:27 -0700 (PDT) Received: from 199-116-72-167.public.monkeybrains.net ([199.116.72.167] helo=[192.168.0.4]) by masada.superduper.net with esmtpsa (TLS1.0:RSA_ARCFOUR_MD5:128) (Exim 4.80) (envelope-from ) id 1YtGii-0006QC-Ss; Fri, 15 May 2015 15:36:15 +0100 From: Simon Barber To: Jim Gettys , "Bill Ver Steeg (versteb)" Date: Fri, 15 May 2015 07:36:08 -0700 Message-ID: <14d5800ec08.27f7.e972a4f4d859b00521b2b659602cb2f9@superduper.net> In-Reply-To: References: <8C015B1B-EFBA-4647-AD83-BAFDD16A4AF2@netapp.com> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 AquaMail/1.5.0.19 (build: 2100846) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----------14d5800fb9a176227f743194728" X-Spam-Score: -2.9 (--) Cc: cake@lists.bufferbloat.net, "Klatsky, Carl" , 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: Fri, 15 May 2015 14:37:21 -0000 This is a multi-part message in MIME format. ------------14d5800fb9a176227f743194728 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit 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 maintain a minimum queue size of at least 64 packets, and sometimes more. Will TCP small queues prevent this? Simon Sent with AquaMail for Android http://www.aqua-mail.com On May 15, 2015 6:44:21 AM Jim Gettys wrote: > On Fri, May 15, 2015 at 9:09 AM, Bill Ver Steeg (versteb) > wrote: > > > Lars- > > > > You make some good points. It boils down to the fact that there are > > several things that you can measure, and they mean different things. > > > > Bvs > > > > > > -----Original Message----- > > From: Eggert, Lars [mailto:lars@netapp.com] > > Sent: Friday, May 15, 2015 8:44 AM > > To: Bill Ver Steeg (versteb) > > Cc: Aaron Wood; cake@lists.bufferbloat.net; Klatsky, Carl; > > cerowrt-devel@lists.bufferbloat.net; bloat > > Subject: Re: [Bloat] [Cerowrt-devel] heisenbug: dslreports 16 flow test vs > > cablemodems > > > > > > 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 the > > same queues. > > > > ​On recent versions of Linux and Mac, you can get most of the socket > buffers to "go away". I forget the socket option offhand.​ > > ​And TCP small queues in Linux means that Linux no longer gratuitously > generates packets just to dump them into the queue discipline system where > they will rot. > > How accurate this now can be is still an interesting question: but has > clearly improved the situation a lot over 3-4 years ago.​ > > > > > If you can instrument TCP in the kernel to make instantaneous RTT > > available to the application, that might work. I am not sure how you would > > roll that out in a timely manner, though. > > > > ​Well, the sooner one starts, the sooner it gets deployed.​ > > Jim > > > > ---------- > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat > ------------14d5800fb9a176227f743194728 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: 8bit

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 maintain a minimum queue size of at least 64 packets, and sometimes more. Will TCP small queues prevent this?

Simon

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

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



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

You make some good points. It boils down to the fact that there are several things that you can measure, and they mean different things.

Bvs


-----Original Message-----
From: Eggert, Lars [mailto:lars@netapp.com]
Sent: Friday, May 15, 2015 8:44 AM
To: Bill Ver Steeg (versteb)
Cc: Aaron Wood; cake@lists.bufferbloat.net; Klatsky, Carl; cerowrt-devel@lists.bufferbloat.net; bloat
Subject: Re: [Bloat] [Cerowrt-devel] heisenbug: dslreports 16 flow test vs cablemodems


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 the same queues.

​On recent versions of  Linux and Mac, you can get most of the socket buffers to "go away".  I forget the socket option offhand.​
 
​And TCP small queues in Linux means that Linux no longer gratuitously generates packets just to dump them into the queue discipline system where they will rot.

How accurate this now can be is still an interesting question: but has clearly improved the situation a lot over 3-4 years ago.​


> If you can instrument TCP in the kernel to make instantaneous RTT available to the application, that might work. I am not sure how you would roll that out in a timely manner, though.

​Well, the sooner one starts, the sooner it gets deployed.​

Jim

_______________________________________________
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

------------14d5800fb9a176227f743194728--