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

Aaron Falk <aaron.falk@gmail.com> Fri, 20 March 2015 15:18 UTC

MIME-Version: 1.0
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]
Precedence: list

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.

Cheers,

--aaron


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

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)
<https://datatracker.ietf.org/wg/taps/charter/>

[2] IAB Stack Evolution Program
<https://www.iab.org/activities/programs/ip-stack-evolution-program/>

[3] Session Protocol for User Datagrams (SPUD) Prototype
<https://tools.ietf.org/html/draft-hildebrand-spud-prototype-00>

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

[5] Subscription link to HOPS mailing list.
<https://www.ietf.org/mailman/listinfo/hops>

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

[hops] Fwd: BarBoF: How Ossified is the Protocol … Aaron Falk