[Cerowrt-devel] [aqm] ping loss "considered harmful"

[Andrew Mcgregor]

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 <david at 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
> aqm at ietf.org
> https://www.ietf.org/mailman/listinfo/aqm
>



-- 
Andrew McGregor | SRE | andrewmcgr at google.com | +61 4 1071 2221
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/cerowrt-devel/attachments/20150303/873f195e/attachment-0002.html>