From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qa0-x229.google.com (mail-qa0-x229.google.com [IPv6:2607:f8b0:400d:c00::229]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id A2DFD21F29C for ; Mon, 2 Mar 2015 16:07:27 -0800 (PST) Received: by mail-qa0-f41.google.com with SMTP id x12so25802227qac.0 for ; Mon, 02 Mar 2015 16:07:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=9KYZFB7xecgx4iya+ZWIUejmJJvqQsVZAt+810pAfe4=; b=FubUjaOFlbYZrlnu5DLLbK38Rq5LoLqf/UzcA8hjlbKJ/K9qIFZlgjUzZe8ANSF+iP nIyI6a4Mt7w2M/TTsmZtk/S0EHUzOAShe3lwzdXcZwOGRoFXnpX4kq5n3jtHIT8TaywX +V6o/Dvh3Sw3Qy82DpdJXByg+zJ5X8t6Rg8ic6ihPk9trF0/8ePZGjRUEJuX4qzybuCz BZUN/kToFYl4diylT7ZOpRkAxcN7+rBc6qZsufJBZv0UaVwqDEvjQtmI03HDgTfdra8j FVeo7WjMDoJaupP45jk3QhW8mdKleGFqSgPKggAJZZjjdWdNINQHOxkGuNcSnCQjp0YO v5OA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=9KYZFB7xecgx4iya+ZWIUejmJJvqQsVZAt+810pAfe4=; b=k6OvDFnRLfIGFGu3aFyhWoqikJCP4cFqYopOcjfrk2epxBTJHDyqOBW0oYLyGB0pL1 ySM42BHluK271pxnehbgb4VhY8pi58MZSBNVEgcGwMyHO3yX9blgw3b1Z34Ta2Bh54gp pP3ao9uz5rdPE5gPTz488WsRfsBgk8Rja4dECqWsg388ISWxaSQHByYHcBA9dw+f48Qq 19aliaQ/f8Q6wGre17yQ7hpM0tYwAWJ7ppXSSDYOGw/wLxT8i9FoRulzWUWCSDbeHuyK 7pzbhlEw1IpzmZB4raqCJPawpxkV47gpXeFgHNC8v5n9EQ2g/zO2brEVIipB3BGzAukd J3Kw== X-Gm-Message-State: ALoCoQmDtlRE/jRHfy+XEESo4SzbIkA1jbHb4P2h0bXlvsqc8l8KGVTcHTnuO1+eASlB537Rk9w4 MIME-Version: 1.0 X-Received: by 10.140.86.75 with SMTP id o69mr53638510qgd.98.1425341245944; Mon, 02 Mar 2015 16:07:25 -0800 (PST) Received: by 10.96.68.74 with HTTP; Mon, 2 Mar 2015 16:07:25 -0800 (PST) In-Reply-To: References: <7B3E53F5-2112-4A50-A777-B76F928CE8F2@trammell.ch> <54F4DBC9.1010700@isi.edu> <54F4F166.6040303@isi.edu> Date: Tue, 3 Mar 2015 11:07:25 +1100 Message-ID: From: Andrew Mcgregor To: David Lang Content-Type: multipart/alternative; boundary=001a11c13e26a613f90510571eb6 Cc: Joe Touch , Avery Pennarun , "cerowrt-devel@lists.bufferbloat.net" , bloat , Brian Trammell , "aqm@ietf.org" Subject: Re: [Cerowrt-devel] [aqm] ping loss "considered harmful" X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2015 00:07:56 -0000 --001a11c13e26a613f90510571eb6 Content-Type: text/plain; charset=UTF-8 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 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@ietf.org > https://www.ietf.org/mailman/listinfo/aqm > -- Andrew McGregor | SRE | andrewmcgr@google.com | +61 4 1071 2221 --001a11c13e26a613f90510571eb6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Maybe I should mention=C2=A0https://github.com/apenwarr/blip

HTTP= ping, using deliberate 204 responses.=C2=A0 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@lang.hm> wrote:
On Mon, 2 Mar 2015, J= oe 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<= br> 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
=C2=A0 =C2=A0 there are dozens of these

2. needing a reflector
=C2=A0 =C2=A0 ping gets around this only because the reflector is widely =C2=A0 =C2=A0 deployed (and integrated into most OSes)

3. using the same port as the traffic you care about
=C2=A0 =C2=A0 transport protocol is only one problem (ICMP being a "tr= ansport
=C2=A0 =C2=A0 protocol" by virtue of using the IP protocol number fiel= d)

=C2=A0 =C2=A0 the other is differential prioritization based on port number=

=C2=A0 =C2=A0 there's no easy solution to that;
=C2=A0 =C2=A0 every service would need an integrated
=C2=A0 =C2=A0 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.<= br>

well, this is exactly the sort of thing that http heartbeat (the core of he= artbleed) was designed to provide.

It's not perfect, you can see where you really get the response from (v= i the traceroute), and if you are going through a MITM (i.e. transparent pr= oxy), all you are ever going to be able to test is the network between your= self and the proxy. It's up to the people who own the proxy to test bey= ond that.

David Lang


_______________________________________________
aqm mailing list
aqm@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/aqm



--
=
Andrew McGregor=C2=A0|=C2=A0SRE=C2=A0|=C2=A0andrewmcgr@google.com=C2=A0|=C2=A0+61 4 1071 2221
--001a11c13e26a613f90510571eb6--