From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) (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 AA10621F3F2; Fri, 15 May 2015 06:35:37 -0700 (PDT) Received: by wgnd10 with SMTP id d10so110798649wgn.2; Fri, 15 May 2015 06:35:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=Lpsq3S7I5Q/uJkiykcC0oJIO8S+M8iTkLLnXu1ptaZ0=; b=WjAHFrEEVnwj26+6dlwbTzQWoq/5pewx3JmXPCh75jf+87GKk21aBZC3QaSIlBss7a w7WpEgiRkZd0D92lbijm7FmvlW2eXEUD9D0hWV3mrCZqhD2K4Ki0UWaSm+pQGzKMV9Ez WKgPQzXYz8Ci75mwdPtQBi4kdPD57dgmVDDG9fNxbNV8ZZ+V4cowfUfYAzWoELgYdI9o osC9HCCCg3DdJg3BiqiDYwO9I+tw1z+mL/JrZt2Z7Xxv3uv9kZLGli6sYIRIchvTm6Qg EEmMH0fYuGXExU+OyXTuqTbj+3inn1vGuN4YW/iqY9nD770qfYO3kHiyNU4lZQYdpQBX TjUQ== MIME-Version: 1.0 X-Received: by 10.195.11.3 with SMTP id ee3mr5535429wjd.89.1431696935913; Fri, 15 May 2015 06:35:35 -0700 (PDT) Sender: gettysjim@gmail.com Received: by 10.194.118.166 with HTTP; Fri, 15 May 2015 06:35:35 -0700 (PDT) In-Reply-To: References: <8C015B1B-EFBA-4647-AD83-BAFDD16A4AF2@netapp.com> Date: Fri, 15 May 2015 09:35:35 -0400 X-Google-Sender-Auth: ZDHMRYpIAa8g8QcAWd2inqSxzDM Message-ID: From: Jim Gettys To: "Bill Ver Steeg (versteb)" Content-Type: multipart/alternative; boundary=047d7b874e504a8ed805161eeb39 Cc: "cake@lists.bufferbloat.net" , "Klatsky, Carl" , "Eggert, Lars" , "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 13:36:07 -0000 --047d7b874e504a8ed805161eeb39 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 v= s > 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 rel= y > on the network to not prioritize ICMP/UDP but otherwise leave it in the > same queues. > =E2=80=8BOn recent versions of Linux and Mac, you can get most of the sock= et buffers to "go away". I forget the socket option offhand.=E2=80=8B =E2=80=8BAnd TCP small queues in Linux means that Linux no longer gratuitou= sly 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.=E2=80=8B > > 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 woul= d > roll that out in a timely manner, though. > > =E2=80=8BWell, the sooner one starts, the sooner it gets deployed.=E2=80= =8B Jim --047d7b874e504a8ed805161eeb39 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Fri, Ma= y 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.c= om]
Sent: Friday, May 15, 2015 8:44 AM
To: Bill Ver Steeg (versteb)
Cc: Aaron Wood; cake@lists.bu= fferbloat.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 app= lication over TCP will see, but not get an accurate estimate of that (becau= se 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 queu= es.

=E2=80=8BOn recent versions = of =C2=A0Linux and Mac, you can get most of the socket buffers to "go = away".=C2=A0 I forget the socket option offhand.=E2=80=8B
=C2=A0<= /div>
=E2=80=8BA= nd TCP small queues in Linux means that Linux no longer gratuitously genera= tes packets just to dump them into the queue discipline system where they w= ill rot.

How accurate thi= s now can be is still an interesting question: but has clearly improved the= situation a lot over 3-4 years ago.=E2=80=8B


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

=E2=80=8BWell, the sooner= one starts, the sooner it gets deployed.=E2=80=8B

Jim

--047d7b874e504a8ed805161eeb39--