Re: [hops] Proposed HOPS Research Group charter

Aaron Falk <aaron.falk@gmail.com> Tue, 12 May 2015 17:09 UTC

Return-Path: <aaron.falk@gmail.com>
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 B628B1ACD54 for <hops@ietfa.amsl.com>; Tue, 12 May 2015 10:09:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.699
X-Spam-Level:
X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] 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 F_fPFC_LqVWa for <hops@ietfa.amsl.com>; Tue, 12 May 2015 10:09:43 -0700 (PDT)
Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (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 717221ACD4F for <hops@ietf.org>; Tue, 12 May 2015 10:09:42 -0700 (PDT)
Received: by igbsb11 with SMTP id sb11so20772078igb.0 for <hops@ietf.org>; Tue, 12 May 2015 10:09:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=l2cnb3FFRY7+cOleD+Zjw3bISc3yvaDlPtoSZ102MrM=; b=YhF+VEx9gffysZPSYXsrQ8tVZ3yC4efUZzoSbiXX/HYsAu7rNNZbuPkpw6iyOuzrJd zfoW6SmPi1ArujWLl2IZF3DGPyHweB4KN/J+c9E0oRh2H3AIOAyaN4IqDbqn8VOaeoUY sNKfWjSIrmnDoA1JBLMaSBIl0wug+N99LPNtLyrt2RWgkEKeHOvyrutauAVR28Wdi/m7 Gah8HY2bWr5HWpLgOtefh248UM6CzPRjdzOOc/CS9Lv2L07BjnTxOth5rVUtHZJS64CN jL10lA2MSrgl3sBwtxsXVlgNKpy2AWyIu5Gn5f3tVzEYRrvX6IGZ+A6tQGS7w30YkSrZ OZuA==
MIME-Version: 1.0
X-Received: by 10.42.100.15 with SMTP id y15mr4211410icn.16.1431450581096; Tue, 12 May 2015 10:09:41 -0700 (PDT)
Received: by 10.64.69.162 with HTTP; Tue, 12 May 2015 10:09:40 -0700 (PDT)
In-Reply-To: <7DDA5783-A6C7-4524-9F76-CFE948461811@trammell.ch>
References: <7DDA5783-A6C7-4524-9F76-CFE948461811@trammell.ch>
Date: Tue, 12 May 2015 13:09:40 -0400
Message-ID: <CAD62q9USH+Zqy-zed6jL+8exBpuRA7Q-Ep-K5kraFtC7w2o-Ow@mail.gmail.com>
From: Aaron Falk <aaron.falk@gmail.com>
To: Brian Trammell <ietf@trammell.ch>, =?UTF-8?Q?Mirja_K=C3=BChlewind?= <mirja.kuehlewind@tik.ee.ethz.ch>
Content-Type: multipart/alternative; boundary=90e6ba615052665e730515e58f02
Archived-At: <http://mailarchive.ietf.org/arch/msg/hops/fap_0w8mzBFkusaD_Q5JlTZh8K0>
Cc: hops@ietf.org
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: Tue, 12 May 2015 17:09:45 -0000

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