Re: [aqm] ping loss "considered harmful"

David Lang <david@lang.hm> Mon, 02 March 2015 23:34 UTC

Return-Path: <david@lang.hm>
X-Original-To: aqm@ietfa.amsl.com
Delivered-To: aqm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4CDF1A8AB4 for <aqm@ietfa.amsl.com>; Mon, 2 Mar 2015 15:34:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pp72DLCkXWLs for <aqm@ietfa.amsl.com>; Mon, 2 Mar 2015 15:34:30 -0800 (PST)
Received: from bifrost.lang.hm (mail.lang.hm [64.81.33.126]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 908831A8AB3 for <aqm@ietf.org>; Mon, 2 Mar 2015 15:34:30 -0800 (PST)
Received: from asgard.lang.hm (asgard.lang.hm [10.0.0.100]) by bifrost.lang.hm (8.13.4/8.13.4/Debian-3) with ESMTP id t22NYOYr028277; Mon, 2 Mar 2015 15:34:24 -0800
Date: Mon, 02 Mar 2015 15:34:24 -0800
From: David Lang <david@lang.hm>
X-X-Sender: dlang@asgard.lang.hm
To: Joe Touch <touch@isi.edu>
In-Reply-To: <54F4F166.6040303@isi.edu>
Message-ID: <alpine.DEB.2.02.1503021532170.5051@nftneq.ynat.uz>
References: <CAA93jw7KW=9PH002d3Via5ks6+mHScz5VDhpPVqLUGK2K=Mhew@mail.gmail.com> <7B3E53F5-2112-4A50-A777-B76F928CE8F2@trammell.ch> <54F4DBC9.1010700@isi.edu> <alpine.DEB.2.02.1503021513060.5051@nftneq.ynat.uz> <54F4F166.6040303@isi.edu>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
Archived-At: <http://mailarchive.ietf.org/arch/msg/aqm/v5e6s9lA8qy2srlxjSITtGuXCeE>
Cc: Brian Trammell <ietf@trammell.ch>, bloat <bloat@lists.bufferbloat.net>, Dave Taht <dave.taht@gmail.com>, "cerowrt-devel@lists.bufferbloat.net" <cerowrt-devel@lists.bufferbloat.net>, "aqm@ietf.org" <aqm@ietf.org>
Subject: Re: [aqm] ping loss "considered harmful"
X-BeenThere: aqm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discussion list for active queue management and flow isolation." <aqm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/aqm>, <mailto:aqm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/aqm/>
List-Post: <mailto:aqm@ietf.org>
List-Help: <mailto:aqm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/aqm>, <mailto:aqm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Mar 2015 23:34:33 -0000

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