From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "alln-iport.cisco.com", Issuer "Cisco SSCA2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 4BAA521F1BD for ; Mon, 25 Aug 2014 14:17:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2650; q=dns/txt; s=iport; t=1409001425; x=1410211025; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=fQi0fhMockMmlzX/4mn3oWjsIQAtsjJm5BpQAJgvzFQ=; b=g8EtFXF/wImfjHIU+dScxsDYR2mPzqPGHkzSFSP7KPLK+E/Oqwt8SZil 9x3vA8Qo6xcNLfsCtMoPHuOVCipDYfGOMIOIa60KXw6kdT5GBEWeB5xaA lNi+UZ8W4g2m6ZHEhzcr0PI/p+OZbdzl5KoZiNPEddewgDKf7cXZD4rqf M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhcFAJyn+1OtJV2a/2dsb2JhbABagw1TVwTMTAyGeFMBgR4Wd4QDAQEBAgEBAQEBNzQLBQcEAgEIEQQBAQsUCQcnAQoUCQgBAQQBDQUIiDIIDcAQF48bMQcGgymBHQWPE4IThCmDd5gPg15sAYFHgQcBAQE X-IronPort-AV: E=Sophos;i="5.04,398,1406592000"; d="scan'208";a="72235665" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-4.cisco.com with ESMTP; 25 Aug 2014 21:17:03 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s7PLH2P3006861 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 25 Aug 2014 21:17:03 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.174]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0195.001; Mon, 25 Aug 2014 16:17:02 -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+AAAYxjIA= Date: Mon, 25 Aug 2014 21:17:01 +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:17:04 -0000 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