[hops] A HOPS Data Wishlist

[Brian Trammell <[e-mail]>]

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"... 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.

Cheers,

Brian