Re: [aqm] ping loss "considered harmful"

Andrew Mcgregor <andrewmcgr@google.com> Tue, 03 March 2015 00:07 UTC

Return-Path: <andrewmcgr@google.com>
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 CF4591A8AEE for <aqm@ietfa.amsl.com>; Mon, 2 Mar 2015 16:07:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.388
X-Spam-Level:
X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
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 mSTvm2C6XRkN for <aqm@ietfa.amsl.com>; Mon, 2 Mar 2015 16:07:27 -0800 (PST)
Received: from mail-qg0-x22d.google.com (mail-qg0-x22d.google.com [IPv6:2607:f8b0:400d:c04::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE05E1A8AED for <aqm@ietf.org>; Mon, 2 Mar 2015 16:07:26 -0800 (PST)
Received: by mail-qg0-f45.google.com with SMTP id z107so8025058qgd.4 for <aqm@ietf.org>; 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=haYBY6fdg0bFcAJTPCZHwNJ53cORYgJfaRSxcI5HL64KbcWvG0qv4XIiupHeOw0NOr /+iVpMOUI60W5l8m/5aDzuCLFzwqtk3FnfINdCJN6SXhnR07x4dyJv5VxqoO77wCZtKP HIOscjHCABAGGnmtT8SsOVcW74rxTvB1KtJcQDynWJcO52gCeX5C2S+S2s2YVTjEZkWJ k0xSpkBQ3ipXy1bnGEVJ/62WDrd9UU2pHmu1XKA16CUhbUtk031OiJb2WSoIvAk8d+Ca MZ4SADOTGF4ai2rU5GzSZtw4v7jJR0JOdbAnMWeuYph2MvFRh5Qvvv8LhKJctgXgcIdS sepQ==
X-Gm-Message-State: ALoCoQkNs1gf/XiikdIM3gYnZOewKVBOiTunrbXNFLllSjHt2pSNP0E6C77pPdS0pxTGhp8WVnNV
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: <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> <alpine.DEB.2.02.1503021532170.5051@nftneq.ynat.uz>
Date: Tue, 3 Mar 2015 11:07:25 +1100
Message-ID: <CAPRuP3kSo4fo9FR76d2cVLHhPCJ_pkQt_x=YQBuHyivLWVyn8w@mail.gmail.com>
From: Andrew Mcgregor <andrewmcgr@google.com>
To: David Lang <david@lang.hm>
Content-Type: multipart/alternative; boundary=001a11c13e26a613f90510571eb6
Archived-At: <http://mailarchive.ietf.org/arch/msg/aqm/B4K65UsH36jzMylGaE51X_GBzMI>
Cc: Joe Touch <touch@isi.edu>, Dave Taht <dave.taht@gmail.com>, Avery Pennarun <apenwarr@google.com>, "cerowrt-devel@lists.bufferbloat.net" <cerowrt-devel@lists.bufferbloat.net>, bloat <bloat@lists.bufferbloat.net>, Brian Trammell <ietf@trammell.ch>, "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: Tue, 03 Mar 2015 00:07:29 -0000

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



-- 
Andrew McGregor | SRE | andrewmcgr@google.com | +61 4 1071 2221