New Non-WG Mailing List: hops -- Measuring deployability of new transport protocols

IETF Secretariat <> Wed, 25 February 2015 18:26 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 45C7A1A1AA3; Wed, 25 Feb 2015 10:26:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=unavailable
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2tNZza0NLPPl; Wed, 25 Feb 2015 10:25:49 -0800 (PST)
Received: from (localhost [IPv6:::1]) by (Postfix) with ESMTP id 424131A0470; Wed, 25 Feb 2015 10:25:49 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: IETF Secretariat <>
To: IETF Announcement List <>
Subject: New Non-WG Mailing List: hops -- Measuring deployability of new transport protocols
X-Test-IDTracker: no
X-IETF-IDTracker: 5.11.2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <>
Date: Wed, 25 Feb 2015 10:25:49 -0800
Archived-At: <>
X-Mailman-Version: 2.1.15
List-Id: "IETF announcement list. No discussions." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 25 Feb 2015 18:26:00 -0000

A new IETF non-working group email list has been created.

List address:
To subscribe:


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. 

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

For additional information, please contact the list administrators.