[hops] A HOPS Data Wishlist

Brian Trammell <ietf@trammell.ch> Tue, 14 April 2015 15:13 UTC

Return-Path: <ietf@trammell.ch>
X-Original-To: hops@ietfa.amsl.com
Delivered-To: hops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 5AD721B2BE9 for <hops@ietfa.amsl.com>; Tue, 14 Apr 2015 08:13:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.912
X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 6YiHCz07pmxT for <hops@ietfa.amsl.com>; Tue, 14 Apr 2015 08:13:55 -0700 (PDT)
Received: from trammell.ch (trammell.ch []) by ietfa.amsl.com (Postfix) with ESMTP id BBE311ACE3C for <hops@ietf.org>; Tue, 14 Apr 2015 08:12:38 -0700 (PDT)
Received: from [IPv6:2001:67c:10ec:2a49:8000::b9] (unknown [IPv6:2001:67c:10ec:2a49:8000::b9]) by trammell.ch (Postfix) with ESMTPSA id E45011A00E5 for <hops@ietf.org>; Tue, 14 Apr 2015 17:12:37 +0200 (CEST)
From: Brian Trammell <ietf@trammell.ch>
X-Pgp-Agent: GPGMail 2.5b6
Content-Type: multipart/signed; boundary="Apple-Mail=_36CDAB1B-679B-4057-843C-24C4E2312438"; protocol="application/pgp-signature"; micalg=pgp-sha512
Date: Tue, 14 Apr 2015 17:12:37 +0200
Message-Id: <3B227409-7598-433D-9589-F484D2315C3D@trammell.ch>
To: hops@ietf.org
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
X-Mailer: Apple Mail (2.2070.6)
Archived-At: <http://mailarchive.ietf.org/arch/msg/hops/Lp23TVqK6Rd9KtxhAnxQ7goqDYE>
Subject: [hops] A HOPS Data Wishlist
X-BeenThere: hops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Measuring deployability of new transport protocols <hops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/hops>, <mailto:hops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hops/>
List-Post: <mailto:hops@ietf.org>
List-Help: <mailto:hops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hops>, <mailto:hops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 14 Apr 2015 15:13:58 -0000

Greetings, all,

At the BarBoF meeting at the IETF in Dallas, I volunteered (or was volunteered, don't recall) to start a "wishlist" of data we would like to see about middlebox impairments in the Internet, as part of an effort to match this up with what we actually think we can get. I answered to the list "see Table 8 in http://rbeverly.net/research/papers/hiccups-sigcomm14.pdf"quot;... but more generally, here's what I think we need, both at the level of results we can use as well as at the level of raw data.

First, for a given protocol or protocol feature, I'd like to know:

(1) what the likelihood is that it will work (i.e. that all the data the option needs to function will not be changed by the path, such as through option stripping), and

(2) what the likelihood is that trying to use it will cause connectivity failure (by dropping packets using the protocol or protocol feature, or worse, as in the infamous case of the old routers that ECN would reboot).

(Once we have answers to those, I'm interested in (3) as well: whether there is a measurable performance penalty in the Internet to the use of an option or protocol as opposed to some other option or protocol, through e.g. slow-pathing, different treatment at the queues, etc, etc, etc. But I'm not sure it's even possible to isolate causality from transient effects in this case, so let's answer the first two, first.)

Of course, every path in the Internet is not created equally. We recently just did an silly little measurement study for a paper under submission which had a bunch of residential and mobile nets and one enterprise network, to see if UDP encaps like SPUD are feasible. If you look at everything other than the enterprise network, the answer is "absolutely". But the enterprise network blocks most/all UDP as a matter of policy. So questions 1 and 2 above probably need at the coarsest grain some information about the type of access at each end of the path.

At a higher level of resolution, what I'd really like to have is a giant table of tuples like this:

{time, path, feature, condition}

where "path" is some identifier for a routable source/destination pair, "feature" is the protocol or extension which we tried to use, and "condition" is what happened ("ok", "stripped", "interfered", "dropped", "reset" etc.). This does not capture everything that would be necessary for building high-resolution models of middlebox behavior (specifically stateful behaviors such as rate limiting, port knocking or port-knocking-like things, etc) but it does allow us to determine whether a path is "possibly clean" or "definitely less than 100% clean".

A path identifier would ideally include a trace of every hop along the path, but that is I know asking for too much. In the routable address domain (i.e. the entire internet that isn't behind a NAT) just source and destination endpoints or prefixes (along with "time" of sufficient resolution) would be enough to tell a lot of things, especially if one presumes that the core doesn't mess with much other than MTU.