From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "rcdn-iport.cisco.com", Issuer "HydrantID SSL ICA G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 14086201904; Fri, 15 May 2015 04:27:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7850; q=dns/txt; s=iport; t=1431689299; x=1432898899; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=zHrzIpDlQn0PHrdMZ9GsYEN1p87fi2UYi8DQObzlQrE=; b=egouldzmpPpV+z/jb6rBDibUnaVoue3VYKQ1nkI0P+2RsU8Wad8Oo4Az 2qgP72tJZQMca9Z7zelMxhg3LLsX1J9b//YNzm1I8f1czvzWvNF0i3g4w 9Qm6p/F5/FHE7oqgVct2uX8b1TMbhzJdqzZTsLg1xE7Ay7OXySY23u462 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AUBQBk11VV/5FdJa1cgkVKVF4GxisBhX8CgT1MAQEBAQEBgQuEIgEBAQQBAipMEAIBCBEEAQELHQchBwoUCQgCBAENBQiIDwMS0T0NhQMBAQEBAQEBAQEBAQEBAQEBAQEBAQEXizqCTYFtGjEGAYMXgRYFkCeCOohAXpFdhncjg3hvgUWBAQEBAQ X-IronPort-AV: E=Sophos;i="5.13,433,1427760000"; d="scan'208,217";a="419951356" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-7.cisco.com with ESMTP; 15 May 2015 11:27:47 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t4FBRlVl011094 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 15 May 2015 11:27:47 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.121]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0195.001; Fri, 15 May 2015 06:27:47 -0500 From: "Bill Ver Steeg (versteb)" To: "Eggert, Lars" , Aaron Wood Thread-Topic: [Bloat] [Cerowrt-devel] heisenbug: dslreports 16 flow test vs cablemodems Thread-Index: AQHQjui69c9aWQ5xNU2UnOoKMUD60p185OHg Date: Fri, 15 May 2015 11:27:47 +0000 Message-ID: References: <8C015B1B-EFBA-4647-AD83-BAFDD16A4AF2@netapp.com> In-Reply-To: <8C015B1B-EFBA-4647-AD83-BAFDD16A4AF2@netapp.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.117.227.39] Content-Type: multipart/alternative; boundary="_000_AE7F97DB5FEE054088D82E836BD15BE9319E6F49xmbalnx05ciscoc_" MIME-Version: 1.0 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 11:28:20 -0000 --_000_AE7F97DB5FEE054088D82E836BD15BE9319E6F49xmbalnx05ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable But the TCP timestamps are impacted by packet loss. You will sometimes get = an accurate RTT reading, and you will sometimes get multiples of the RTT du= e to packet loss and retransmissions. I would hate to see a line classified= as bloated when the real problem is simple packet loss. Head of line block= ing, cumulative acks, yada, yada, yada. You really need to use a packet oriented protocol (ICMP/UDP) to get a true = measure of RTT at the application layer. If you can instrument TCP in the k= ernel to make instantaneous RTT available to the application, that might wo= rk. I am not sure how you would roll that out in a timely manner, though. I= think I actually wrote some code to do this on BSD many years ago, and it = gave pretty good results. I was building a terminal server (remember those?= ) and needed to have ~50ms +- 20ms echo times. Bvs From: bloat-bounces@lists.bufferbloat.net [mailto:bloat-bounces@lists.buffe= rbloat.net] On Behalf Of Eggert, Lars Sent: Friday, May 15, 2015 4:18 AM To: Aaron Wood Cc: cake@lists.bufferbloat.net; Klatsky, Carl; cerowrt-devel@lists.bufferbl= oat.net; bloat Subject: Re: [Bloat] [Cerowrt-devel] heisenbug: dslreports 16 flow test vs = cablemodems On 2015-5-15, at 06:44, Aaron Wood > wrote: ICMP prioritization over TCP? Probably. Ping in parallel to TCP is a hacky way to measure latencies; not only becau= se of prioritization, but also because you don't measure TCP send/receive b= uffer latencies (and they can be large, auto-tuning is not so great.) You really need to embed timestamps in the TCP bytestream and echo them bac= k. See the recent netperf patch I sent. Lars --_000_AE7F97DB5FEE054088D82E836BD15BE9319E6F49xmbalnx05ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

But the TCP timestamps ar= e impacted by packet loss. You will sometimes get an accurate RTT reading, = and you will sometimes get multiples of the RTT due to packet loss and retransmissions. I would hate to see a line classified as bloated= when the real problem is simple packet loss. Head of line blocking, cumula= tive acks, yada, yada, yada.

 <= /p>

You really need to use a = packet oriented protocol (ICMP/UDP) to get a true measure of RTT at the app= lication layer. 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. I thin= k I actually wrote some code to do this on BSD many years ago, and it gave = pretty good results. I was building a terminal server (remember those?) and needed to have ~50ms +- 20ms e= cho times.

 <= /p>

 <= /p>

Bvs

 <= /p>

From: bloat-bo= unces@lists.bufferbloat.net [mailto:bloat-bounces@lists.bufferbloat.net] On Behalf Of Eggert, Lars
Sent: Friday, May 15, 2015 4:18 AM
To: Aaron Wood
Cc: cake@lists.bufferbloat.net; Klatsky, Carl; cerowrt-devel@lists.b= ufferbloat.net; bloat
Subject: Re: [Bloat] [Cerowrt-devel] heisenbug: dslreports 16 flow t= est vs cablemodems

 

On 2015-5-15, at 06:44, Aaron Wood <woody77@gmail.com> wrote:

ICMP prioritization over TCP?

 

Probably.

 

Ping in parallel to TCP is a hacky way to measure la= tencies; not only because of prioritization, but also because you don't mea= sure TCP send/receive buffer latencies (and they can be large, auto-tuning = is not so great.)

 

You really need to embed timestamps in the TCP bytes= tream and echo them back. See the recent netperf patch I sent.

 

Lars

--_000_AE7F97DB5FEE054088D82E836BD15BE9319E6F49xmbalnx05ciscoc_--