Re: [hops] Proposed HOPS Research Group charter

Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch> Wed, 13 May 2015 09:28 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 [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C0ED1ACE08 for <hops@ietfa.amsl.com>; Wed, 13 May 2015 02:28:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.91
X-Spam-Level:
X-Spam-Status: No, score=-3.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, 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 Yf4kZC2j3Szz for <hops@ietfa.amsl.com>; Wed, 13 May 2015 02:28:15 -0700 (PDT)
Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42C231ACDFE for <hops@ietf.org>; Wed, 13 May 2015 02:28:15 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id C9E6BD9309; Wed, 13 May 2015 11:28:13 +0200 (MEST)
X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch
Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id IdNA+OAQN7h2; Wed, 13 May 2015 11:28:13 +0200 (MEST)
Received: from [82.130.103.143] (nb-10510.ethz.ch [82.130.103.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 64651D9305; Wed, 13 May 2015 11:28:13 +0200 (MEST)
Message-ID: <5553192D.6050705@tik.ee.ethz.ch>
Date: Wed, 13 May 2015 11:28:13 +0200
From: =?UTF-8?B?TWlyamEgS8O8aGxld2luZA==?= <mirja.kuehlewind@tik.ee.ethz.ch>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Aaron Falk <aaron.falk@gmail.com>, hops@ietf.org
References: <7DDA5783-A6C7-4524-9F76-CFE948461811@trammell.ch> <CAD62q9USH+Zqy-zed6jL+8exBpuRA7Q-Ep-K5kraFtC7w2o-Ow@mail.gmail.com>
In-Reply-To: <CAD62q9USH+Zqy-zed6jL+8exBpuRA7Q-Ep-K5kraFtC7w2o-Ow@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/hops/nhjbiBskIFcrMtQiR5x8TfGEapU>
Cc: Brian Trammell <ietf@trammell.ch>
Subject: Re: [hops] Proposed HOPS Research Group charter
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: Wed, 13 May 2015 09:28:19 -0000

Hi Aaron,

thanks for your feedback. I think I have addressed all your comments. Find a new 
version below!

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.
<http://conferences.sigcomm.org/imc/2011/docs/p181.pdf>

[2] R. Craven, R. Beverly, and M. Allman.
A middlebox-cooperative TCP for a non end-to-end Internet. In Proc. ACM SIGCOMM, 
2014.
<http://doi.acm.org/10.1145/2619239.2626321>

[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.
<http://www.it.uc3m.es/amandala/c2bid.html>

Objective
---------

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

Membership in the HOPS RG is open.

Meetings
--------

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.



On 12.05.2015 19:09, Aaron Falk wrote:
> Hi Brian & Mirja-
>
> Glad to see this work is moving forward.  An RG seems like the venue.  I have a
> couple of comments on the charter:
>
>   *   I believe one of the more interesting and important elements of the work
>     we discussed was that it was going to focus on measurements made from the
>     edge.  In particular, **active client** measurements are hard to come by.
>     I'd like to see that called out as a focus.
>
>   * Along the same lines, the engagement of folks from major browser & OS
>     distros may open up opportunities that have not been generally available to
>     the measurement community.  Might want to include that as a goal for the
>     group.  I.e., focus on active measurements that are considered feasible for
>     inclusion in well-known end-systems (specifically including mobile & fixed,
>     residential & enterprise).
>
>   * Add a cite to the HICCUPS paper alongside the Honda paper.
>
>
> Some other points from the notes that might be worth including:
>
>   * There may be a substantial amount of data available from clients (such as
>     Chrome or linux) which might be useful if accessible.  Statements from the
>     RG that certain data is useful may make it more likely to be shared.
>
>   * There was an expression of interest by a major network operator in test
>     tools capable of identifying and characterizing problematic middleboxes.
>
>   * There was general agreement that aggregated statistics about the frequency
>     of middlebox behavior could also be very useful.
>
>
> Best regards,
>
> --aaron
>
>
>
> On Tue, May 12, 2015 at 10:56 AM, Brian Trammell <ietf@trammell.ch
> <mailto:ietf@trammell.ch>> wrote:
>
>     Greetings, all,
>
>     Following up on the successful BarBoF in Dallas, we would like to propose a
>     first HOPS (proposed) research group meeting in Prague. The draft charter
>     text is attached for comment.
>
>     Cheers,
>
>     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. In the
>     interest of getting ground-truth data about the nature of the problem, the
>     HOPS research group will provide a discusion 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.
>     <http://conferences.sigcomm.org/imc/2011/docs/p181.pdf>
>
>     Objective
>     ---------
>
>     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.
>
>     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. These active measurements will be useful for targeted questions
>     about specific paths as well as to fill in data not available from passive
>     measurement.
>
>     Membership
>     ----------
>
>     Membership in the HOPS RG is open.
>
>     Meetings
>     --------
>
>     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.
>
>
>     _______________________________________________
>     hops mailing list
>     hops@ietf.org <mailto:hops@ietf.org>
>     https://www.ietf.org/mailman/listinfo/hops
>
>

-- 
------------------------------------------
Dipl.-Ing. Mirja Kühlewind
Communication Systems Group
Institute TIK, ETH Zürich
Gloriastrasse 35, 8092 Zürich, Switzerland

Room ETZ G93
phone: +41 44 63 26932
email: mirja.kuehlewind@tik.ee.ethz.ch
------------------------------------------