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