From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "rcdn-iport.cisco.com", Issuer "Cisco SSCA2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id CE71121F5EF for ; Mon, 25 Aug 2014 14:21:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3369; q=dns/txt; s=iport; t=1409001670; x=1410211270; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=G9XBo9r/yneRwsGE3m+6hu1Sw11G2ni4Wk6SKtbIRXs=; b=AN9PsotVW5wX1x3s4SJ1TW74zUg9d/QFuEWcLlk2f+4JtdwXkbSxKrKS xZIn8VkE1+F3O2pfTIB9NBFxT3eXrSPPWJZ2WvDQAbjydD2I4SuqBkAsN xvBkyTtj3DbpUwfZrhY/6GfKIDcypVlRdqmo9zvsHdp0Ir++Mb064KA0M A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhcFAFuo+1OtJV2R/2dsb2JhbABagw1TVwTMTAyGeFMBgR4Wd4QDAQEBAgEBAQEBNzQLBQcEAgEIEQQBAQsUCQcnAQoUCQgCBAENBQiIMggNwAMXjxsxBwaDKYEdBY8TghOEKYI6gT2YD4NebAGBR4EHAQEB X-IronPort-AV: E=Sophos;i="5.04,398,1406592000"; d="scan'208";a="350237339" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-4.cisco.com with ESMTP; 25 Aug 2014 21:20:55 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s7PLKs0o007385 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 25 Aug 2014 21:20:54 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.174]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0195.001; Mon, 25 Aug 2014 16:20:54 -0500 From: "Bill Ver Steeg (versteb)" To: Sebastian Moeller , Jim Gettys Thread-Topic: [Bloat] The Dark Problem with AQM in the Internet? Thread-Index: Ac++/TegXjuC8IrxQVm08Xz1mNtBdAAObqaAAF652oAAAfSHAAACMG+AAAYxjIAADDvxAA== Date: Mon, 25 Aug 2014 21:20:53 +0000 Message-ID: References: <000001cfbefe$69194c70$3b4be550$@duckware.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.117.75.44] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "bloat@lists.bufferbloat.net" Subject: Re: [Bloat] The Dark Problem with AQM in the Internet? 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: Mon, 25 Aug 2014 21:21:10 -0000 Oops - never mind. I thought the tool was doing traceroute-like things with= varying TTLs in order to get per-hop data.=20 Go back to whatever you were doing...... Bill Ver Steeg Distinguished Engineer=20 Cisco Systems -----Original Message----- From: bloat-bounces@lists.bufferbloat.net [mailto:bloat-bounces@lists.buffe= rbloat.net] On Behalf Of Bill Ver Steeg (versteb) Sent: Monday, August 25, 2014 5:17 PM To: Sebastian Moeller; Jim Gettys Cc: bloat@lists.bufferbloat.net Subject: Re: [Bloat] The Dark Problem with AQM in the Internet? Just a cautionary tale- There was a fairly well publicized DOS attack that = involved TCP SYN packets with a zero TTL (If I recall correctly), so be car= eful running that tool. Be particularly careful if you run it in bulk, as y= ou may end up in a black list on a firewall somewhere...... Bill Ver Steeg Distinguished Engineer=20 Cisco Systems -----Original Message----- From: bloat-bounces@lists.bufferbloat.net [mailto:bloat-bounces@lists.buffe= rbloat.net] On Behalf Of Sebastian Moeller Sent: Monday, August 25, 2014 3:13 PM To: Jim Gettys Cc: bloat@lists.bufferbloat.net Subject: Re: [Bloat] The Dark Problem with AQM in the Internet? Hi Jim, On Aug 25, 2014, at 20:09 , Jim Gettys wrote: > Note that I worked with Folkert Van Heusden to get some options added to = his httping program to allow "ping" style testing against any HTTP server o= ut there using HTTP/TCP. >=20 > See: >=20 > http://www.vanheusden.com/httping/ That is quite cool! >=20 > I find it slightly ironic that people are now concerned about ICMP ping n= o longer returning queuing information given that when I started working on= bufferbloat, a number of people claimed that ICMP Ping could not be relied= upon to report reliable information, as it may be prioritized differently = by routers.=20 Just to add what I learned: some routers seem to have rate limiting for IC= MP processing and process these on a slow-path (see https://www.nanog.org/m= eetings/nanog47/presentations/Sunday/RAS_Traceroute_N47_Sun.pdf ). Mind you= this applies if the router processes the ICMP packet, not if it simply pas= ses it along. So as long as the host responding to the pings is not a route= r with interesting limitations, this should not affect the suitability of I= CMP to detect and measure buffer bloat (heck this is what netperf-wrapper's= RRUL test automated). But since Jerry wants to pinpoint the exact location= of his assumed single packet drop he wants to use ping/traceroute to actua= lly probe routers on the way, so all this urban legends about ICMP processi= ng on routers will actually affect him. But then what do I know... Best Regards Sebastian > This "urban legend" may or may not be true; I never observed it in my exp= lorations. >=20 > In any case, you all may find it useful, and my thanks to Folkert for a v= ery useful tool. >=20 > - Jim >=20 _______________________________________________ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat _______________________________________________ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat