[Bloat] The Dark Problem with AQM in the Internet?

Mon Aug 25 17:20:53 EDT 2014

Oops - never mind. I thought the tool was doing traceroute-like things with varying TTLs in order to get per-hop data. 

Go back to whatever you were doing......

Bill Ver Steeg
Distinguished Engineer 
Cisco Systems

-----Original Message-----
From: bloat-bounces at lists.bufferbloat.net [mailto:bloat-bounces at lists.bufferbloat.net] On Behalf Of Bill Ver Steeg (versteb)
Sent: Monday, August 25, 2014 5:17 PM
To: Sebastian Moeller; Jim Gettys
Cc: bloat at 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 careful running that tool. Be particularly careful if you run it in bulk, as you may end up in a black list on a firewall somewhere......

Bill Ver Steeg
Distinguished Engineer 
Cisco Systems

-----Original Message-----
From: bloat-bounces at lists.bufferbloat.net [mailto:bloat-bounces at lists.bufferbloat.net] On Behalf Of Sebastian Moeller
Sent: Monday, August 25, 2014 3:13 PM
To: Jim Gettys
Cc: bloat at 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 <jg at freedesktop.org> 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 out there using HTTP/TCP.
> 
> See:
> 
> http://www.vanheusden.com/httping/

	That is quite cool!

> 
> I find it slightly ironic that people are now concerned about ICMP ping no 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. 

	Just to add what I learned: some routers seem to have rate limiting for ICMP processing and process these on a slow-path (see https://www.nanog.org/meetings/nanog47/presentations/Sunday/RAS_Traceroute_N47_Sun.pdf ). Mind you this applies if the router processes the ICMP packet, not if it simply passes it along. So as long as the host responding to the pings is not a router with interesting limitations, this should not affect the suitability of ICMP 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 actually probe routers on the way, so all this urban legends about ICMP processing 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 explorations.
> 
> In any case, you all may find it useful, and my thanks to Folkert for a very useful tool.
> 
>                                                   - Jim
> 

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