Subject: Re: [Taps] BarBoF: How Ossified is the Protocol Stack? [HOPS]

From: "Fred Baker (fred)" <[email-masked]>
Date: Wed, 11 Mar 2015 14:25:48 +0000

I’m interested but already have an activity that evening. Will there be some posted summary?

> On Feb 25, 2015, at 10:33 AM, Aaron Falk <[email-masked]> wrote:
> 
> 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)
> 
> [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
> 
> 
> _______________________________________________
> Taps mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/taps

---

From: Aaron Falk <[email-masked]>
Date: Wed, 11 Mar 2015 10:35:49 -0400

Yup.  It'll go out to the HOPS mail list so you can find it in the archives
if you aren't subscribed.

--aaron

On Wed, Mar 11, 2015 at 10:25 AM, Fred Baker (fred) <[email-masked]> wrote:

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