[hops] Proposal for HOPS RG

Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch> Fri, 22 May 2015 11:14 UTC

Return-Path: <mirja.kuehlewind@tik.ee.ethz.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 C5F341B2B95 for <hops@ietfa.amsl.com>; Fri, 22 May 2015 04:14:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.011
X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, 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 WsNOduVXYGzm for <hops@ietfa.amsl.com>; Fri, 22 May 2015 04:14:26 -0700 (PDT)
Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AE711B2B8A for <hops@ietf.org>; Fri, 22 May 2015 04:14:26 -0700 (PDT)
Received: from localhost (localhost []) by smtp.ee.ethz.ch (Postfix) with ESMTP id 873E7D9303; Fri, 22 May 2015 13:14:24 +0200 (MEST)
X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch
Received: from smtp.ee.ethz.ch ([]) by localhost (.ee.ethz.ch []) (amavisd-new, port 10024) with LMTP id v49wBj9+rPJL; Fri, 22 May 2015 13:14:24 +0200 (MEST)
Received: from [] (x5f7009d4.dyn.telefonica.de []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 1685BD9302; Fri, 22 May 2015 13:14:24 +0200 (MEST)
From: =?utf-8?Q?Mirja_K=C3=BChlewind?= <mirja.kuehlewind@tik.ee.ethz.ch>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Date: Fri, 22 May 2015 13:14:25 +0200
Message-Id: <A8A13A5E-ECF7-475D-A18B-E78E409C16AA@tik.ee.ethz.ch>
To: "Eggert, Lars (lars@netapp.com)" <lars@netapp.com>
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
X-Mailer: Apple Mail (2.2098)
Archived-At: <http://mailarchive.ietf.org/arch/msg/hops/Lx5t4dq06zUmf4-a9IlqUm5n0b4>
Cc: hops@ietf.org, Brian Trammell <trammell@tik.ee.ethz.ch>
Subject: [hops] Proposal for HOPS RG
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: Fri, 22 May 2015 11:14:30 -0000

Hi Lars,

as you might have seen in the mean time, we would like to propose a new HOPS research group. Based on the fruitful discuss we had at the BarBoF in Dallas and further discussions with individuals we think that this topic is appropriate for a research group and send a proposed charter text with this mail (see below). Our goal would be to provide a forum to exchange and discuss measurement results and methodology on middlebox impairments. Further we’d also like work on a common data format that can be used to specify impairment tests to achieve comparable results from different existing and new data sets independent of the technique that was used to collect this data. We think that a research group is also the appropriate form for this activity. See further details below.

In parallel we’ve been also talking to people how indicated interest at the BarBoF as well as further people from the research community to figure out if there is interest in giving a presentation at a potential rg meeting. We have received large interest and are positive that people will be able to actually present data at such a meeting. See a tentative agenda for a potentially first meeting in Prague below.

Let us know what you think or if you have any further questions!

Brian and Mirja


How Ossified is the Protocol Stack? (HOPS)

There has been long term and increasing interest in deploying transport protocols with alternate dynamics and behaviors to TCP and UDP. The IETF has standardized several new protocols including DCCP, UDP-lite, SCTP and several changes to TCP including ECN and LEDBAT. All of these new technologies have resulted in deployment challenges blamed on intentional and unintentional interference by middleboxes such as NATs and firewalls. This has lead to approaches such as building new protocols over UDP or HTTP to make traffic look like something a middlebox would expect. However, both these approaches have shortcomings and a variety of ameliorating engineering approaches are being considered.

What is missing is a study with more than anecdotal evidence of the nature of the problem and the portions of the network in which it manifests. One of the best analyses to date is [1] which measures from a very small number of locations: 49 residential, 17 enterprise, and 142 locations in total. There are two more recent studies: [2] is focusing on TCP in-band testing while using PlanetLab as a measurement testbed; [2] use crowd-sourcing with in total 1,165 workers from 53 different countries covering a larger set of access networks including mobile access for TLS testing [3]. However, to be able to draw conclusions about the significance of a certain middlebox interference problem more data form a large variety of access networks is needed. In the interest of getting ground-truth data about the nature of the problem, the HOPS research group will provide a discussion forum to coordinate efforts in research and industry -- such as network stack, browser, and middlebox vendors, as well as network and service operators -- on collecting and reporting statistics about middlebox impact on transport sessions.

[1] M. Honda, Y. Nishida, C. Raiciu, A. Greenhalgh, M. Handley, and H. Tokuda.
Is it still possible to extend tcp? In Proc. ACM IMC, 2011.

[2] R. Craven, R. Beverly, and M. Allman.
A middlebox-cooperative TCP for a non end-to-end Internet. In Proc. ACM SIGCOMM, 2014.

[3] A. M. Mandalari, M. Bagnulo, A. Lutu.
Informing Protocol Design Through Crowdsourcing: the Case of Pervasive Encryption.
ACM SIGCOMM Workshop on Crowdsourcing and crowdsharing of Big (Internet) Data (C2B(I)D), 2015.


The HOPS research group follows from the successful BarBoF meeting organized by Aaron Falk at IETF92 in Dallas to bring more data on the nature and extent of middlebox interference to protocol design and engineering efforts. To this end, we aim to provide a forum for discussion and exchange of measurement insights, data, and techniques co-located with IETF meetings. The BarBoF identified the need for this forum, with many participants wanting a place to continue these discussions.

In addition, we have identified two near-term goals to be completed within the research group in support of this work.

First is the definition of a common format for reporting on middlebox impairments observed in the network, whether these observations are made passively, actively, or as a side effect of some other operation, e.g. taken from application or network stack error logs. This common format must provide for correlation and comparison among data from disjoint observations, and address end-user privacy and business confidentiality concerns, e.g. using path pseudonyms instead of paths identified by AS number and/or IP address where necessary. These measurements should be useful not only for detecting impairments but also for assessing the likelihood that a certain impairment will be experienced by traffic on certain types of networks and in the Internet as a whole. For this purpose aggregated statistics on the prevalence of certain middblebox behaviors are useful, even without revealing the underlying measurement data.

Second is the specification of methods for analysis of middlebox interference, and associated active measurement techniques, that can scale to much larger numbers of measured paths than those presently in the literature, while minimizing network measurement traffic load on the network. Similar techniques could be used for middlebox benchmarking. Focusing on active measurements that are considered feasible for inclusion in well-known end-systems (e.g. in browsers or the OS) has been identified as way forward to collect more data and reach a high coverage of different access networks, specifically including mobile and fixed, residential, as well as enterprise network. These active measurements will be useful for targeted questions about specific paths as well as to fill in data not available from passive measurement. Further, providing guidelines on with measurement and analysis techniques are needed to detect and classify certain impairments may increase the willingness of industry to share data that is already available.


Membership in the HOPS RG is open.


The HOPS RG will meet one to three times per year, initially always co-located with IETF meetings, to foster exchange among researchers and between research and industry on middlebox measurement topics. Meetings may in the future be scheduled to provide additional interaction with the network operations community, should operationally relevant and useful results warrant this.

We aim to hold a first meeting at IETF 93 in Prague, and already have a number of presentation confirmed leading to the following tentative agenda:

1) Welcome and Intro

2) Passive Measurement Data
  - "Results from deployment of QUIC, a UDP-based transport" Jana Iyengar (Google)
  - Dave Plonka (Akamai) (not fully confirmed yet)

3) Active Measurements
  - Robert Kisteleki (RIPE) (title tbd)
  - "Lessons learnt from middlebox measurement” Michio Honda (NetApp)

4) Measurement Methodology
  - "Tracking Middleboxes with Tracebox" Korian Edeline (Université de Liège)