[hops] Fwd: BarBoF: How Ossified is the Protocol Stack? [HOPS]

Aaron Falk <aaron.falk@gmail.com> Fri, 20 March 2015 15:18 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 []) by ietfa.amsl.com (Postfix) with ESMTP id 738D51A0276 for <hops@ietfa.amsl.com>; Fri, 20 Mar 2015 08:18:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 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, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id UfgyL5x9AuBy for <hops@ietfa.amsl.com>; Fri, 20 Mar 2015 08:18:09 -0700 (PDT)
Received: from mail-ig0-x236.google.com (mail-ig0-x236.google.com [IPv6:2607:f8b0:4001:c05::236]) (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 0FE201A01A9 for <hops@ietf.org>; Fri, 20 Mar 2015 08:18:09 -0700 (PDT)
Received: by igbqf9 with SMTP id qf9so20528636igb.1 for <hops@ietf.org>; Fri, 20 Mar 2015 08:18:08 -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 :content-type; bh=LHtT+nGFDehmoERpeFi/fYhb8xtI77XKQ6h79H8bLSI=; b=Jk92WIFc505ThlUwfIkCSwdnZTN0Tyw/UKSJRishLciZWQqWh7nkp07sjlkLSs8Vkq lVVe7SA+S3/LeehY2KOzsvuY/HKFkbP5yxEIBE4VDXtmlLj+YJ+0Wea3TK22qe9juEfq u9cBDV12DdAl08SDaeLUkm4EYWhWkrF8dXxldwamDxD0Hp715h3Rp3ly3/xFcG/J6iXL EFUho+c9c5sIHJqMxjqFeh5TlB9yVs35PF89z2gGgr8Ltu3wxh8cQeA3RPdafSNh6CdH KE6CMRx2NUZ6IWucTUidEUMQiM/GfV/4mY0mnVTbL4JL5n175f5keSiNmJK9mjGUOA7c woJg==
MIME-Version: 1.0
X-Received: by with SMTP id s1mr4914212icm.16.1426864688014; Fri, 20 Mar 2015 08:18:08 -0700 (PDT)
Received: by with HTTP; Fri, 20 Mar 2015 08:18:07 -0700 (PDT)
In-Reply-To: <CAD62q9VCrGrtP6kNYPqYTu7B9HJufuCUSSFb+yE7vpCPy1NW6A@mail.gmail.com>
References: <CAD62q9VCrGrtP6kNYPqYTu7B9HJufuCUSSFb+yE7vpCPy1NW6A@mail.gmail.com>
Date: Fri, 20 Mar 2015 11:18:07 -0400
Message-ID: <CAD62q9U7JZ67RWXRjxe9t9FrFGMaYVhsYz_G4e0a5vQTmu1OkQ@mail.gmail.com>
From: Aaron Falk <aaron.falk@gmail.com>
To: hops@ietf.org
Content-Type: multipart/alternative; boundary=90e6ba614bfcdf2b790511b9d20e
Archived-At: <http://mailarchive.ietf.org/arch/msg/hops/d5pMJDkTJlvynrGStKylTBVB6LA>
Subject: [hops] Fwd: BarBoF: How Ossified is the Protocol Stack? [HOPS]
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, 20 Mar 2015 15:18:11 -0000

Hi Folks-

I've deliberately held off from online discussion before the barbof on
Sunday so we could have some higher-bandwidth f2f discussion first.
However, I do suggest that you take a look at the Honda, et al, paper [4]
beforehand to get some context.



---------- Forwarded message ----------
From: Aaron Falk <aaron.falk@gmail.com>
Date: Wed, Feb 25, 2015 at 11:21 AM
Subject: BarBoF: 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 [1], [2], [3].

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 [4] 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,
we are organizing an informal effort starting with a meeting (BarBoF) at
the March IETF in Dallas to coordinate with network stack, browser, and
middlebox vendors, as well as network and service operators, on collecting
and reporting statistics about middlebox impact on transport sessions. The
objective is to determine a set of measurements that can be made as a side
effect of the normal operation of the networking stack, and a reporting
format that provides some visibility into the scope and nature of middlebox
impact while addressing end-user privacy and business confidentiality

The BarBoF meeting will be Sunday evening (March 22nd).  Time & location to
be announced on the mailing list [5].

This activity is an outcome of the recent IAB workshop on Stack Evolution
in a Middlebox Internet [6].

Please forward to anyone interested in participating.


[1] IETF Transport Services Working Group (TAPS)

[2] IAB Stack Evolution Program

[3] Session Protocol for User Datagrams (SPUD) Prototype

[4] 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.

[5] Subscription link to HOPS mailing list.

[6] IAB SEMI Workshop <https://www.iab.org/activities/workshops/semi/>