Maybe I should mention https://github.com/apenwarr/blip
HTTP ping, using deliberate 204 responses. Will run over whatever version of HTTP/SPDY/QUIC your browser happens to be using at the time. On 3 March 2015 at 10:34, David Lang <da...@lang.hm> wrote: > On Mon, 2 Mar 2015, Joe Touch wrote: > > On 3/2/2015 3:14 PM, David Lang wrote: >> >>> On Mon, 2 Mar 2015, Joe Touch wrote: >>> >>> On 3/2/2015 1:40 AM, Brian Trammell wrote: >>>> ... >>>> >>>>> The real solution is to create a utility called "ping" that uses >>>>> traffic that gets prioritized the same way as the traffic you care >>>>> about instead of ICMP echo request/reply. Users don't care about >>>>> the packets on the wire so much as they do that you're supposed to >>>>> ping things. >>>>> >>>> >>>> There are three separate problems: >>>> >>>> 1. a ping that doesn't use ICMP >>>> there are dozens of these >>>> >>>> 2. needing a reflector >>>> ping gets around this only because the reflector is widely >>>> deployed (and integrated into most OSes) >>>> >>>> 3. using the same port as the traffic you care about >>>> transport protocol is only one problem (ICMP being a "transport >>>> protocol" by virtue of using the IP protocol number field) >>>> >>>> the other is differential prioritization based on port number >>>> >>>> there's no easy solution to that; >>>> every service would need an integrated >>>> ping reflector >>>> >>>> I suspect #3 is the ultimate killer of this idea. >>>> >>> >>> The service you are trying to contact acts as a reflector for TCP >>> traffic. If you send a syn you will get back a syn-ack from the TCP >>> stack of the receiving system. >>> >> >> Sure, but SYNs and SYN-ACKs don't get prioritized the same as >> non-control TCP segments. And they could have been spoofed by a middlebox. >> > > well, this is exactly the sort of thing that http heartbeat (the core of > heartbleed) was designed to provide. > > It's not perfect, you can see where you really get the response from (vi > the traceroute), and if you are going through a MITM (i.e. transparent > proxy), all you are ever going to be able to test is the network between > yourself and the proxy. It's up to the people who own the proxy to test > beyond that. > > David Lang > > > _______________________________________________ > aqm mailing list > a...@ietf.org > https://www.ietf.org/mailman/listinfo/aqm > -- Andrew McGregor | SRE | andrewm...@google.com | +61 4 1071 2221
_______________________________________________ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel