Re: [tcmtf] Thank you for a great BoF!

Brian Trammell <> Wed, 12 March 2014 09:00 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 1D55A1A092A for <>; Wed, 12 Mar 2014 02:00:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JCr6RyrGb806 for <>; Wed, 12 Mar 2014 02:00:02 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 401421A091F for <>; Wed, 12 Mar 2014 02:00:02 -0700 (PDT)
Received: from [] ( []) by (Postfix) with ESMTPSA id ABBEE1A1077; Wed, 12 Mar 2014 09:59:54 +0100 (CET)
Content-Type: multipart/signed; boundary="Apple-Mail=_E95494B2-B819-47C7-AE97-B74FA76365DA"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Brian Trammell <>
In-Reply-To: <008301cf3dcc$52b8f6f0$f82ae4d0$>
Date: Wed, 12 Mar 2014 09:59:53 +0100
Message-Id: <>
References: <> <> <008301cf3dcc$52b8f6f0$f82ae4d0$>
To: Jose Saldana <>
X-Mailer: Apple Mail (2.1874)
Cc:, Martin Stiemerling <>, Spencer Dawkins <>
Subject: Re: [tcmtf] Thank you for a great BoF!
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Tunneling Compressed Multiplexed Traffic Flows \(TCMTF\) discussion list" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 12 Mar 2014 09:00:06 -0000

Greetings, all,

(as individual contributor, BoF chair hat off since, indeed, the BoF is over. :) )

A couple of points, inline...

On 12 Mar 2014, at 09:23, Jose Saldana <> wrote:

> Hi, Martin,
> According to the summary of Brian and Mirja, there are three potential
> improvements for the TCM-TF charter draft. I have added some comments below.
> Should we prepare a new version of the charter?
>> -----Mensaje original-----
>> De: tcmtf [] En nombre de Brian Trammell
>> Enviado el: miƩrcoles, 05 de marzo de 2014 14:51
>> Para:
>> Asunto: [tcmtf] Thank you for a great BoF!
>> Greetings, all,
>> Thanks to everyone for yesterday's BoF. We got lots of good input, and a
>> better handle on what a future TCMTF WG might look like.
>> There are a few issues we identified that we'll have to take into
>> consideration for a new draft of the charter:
>> (1) make it clear that backward compatibility with RFC 4170 is a goal.
> I think there is no problem with maintaining backwards compatibility. I sent
> some suggestions for improving the charter:

While it was _somewhat_ clear that backward compatibility was desired, it wasn't explicit in the charter, and some people found that confusing. Simply making it explicit (i.e., ensuring the phrase "backward compatible with 4170" appears in the charter text) fixes this problem.


>> This should address interactions between
>>    TCMTF tunnels and TCP cross traffic sharing a bottleneck link.
> This should have to be added to the charter, but I don't clearly understand
> what is this problem about. If we compress UDP flows, then we have more
> bandwidth for TCP flows sharing the bottleneck. Where is the problem?
> Perhaps I missed something in the discussion.

If you're compressing UDP flows to get them out of the way of concurrent TCP traffic, this is what you want. It's a problem if the reason you're doing UDP header compression is to get more bandwidth for UDP flows, or to reduce losses on the UDP flows on a congested link, since concurrent TCP traffic will always use all the bandwidth it can while inducing packet loss (necessary for the operation of loss-based congestion control) on all flows sharing the bottleneck link.

This is a key point to account for when running TCP and TCM across the same bottleneck link: congestion control will induce loss, implying that any header compression scheme in such a scenario will have to be relatively loss tolerant. I'm not really up on the details of the compression technologies proposed, but we'll have to have a good understanding of the packet loss amplification properties thereof. RFC 3545 seems to imply that ECRTP is relatively loss and reordering tolerant. ROHC is rather a complicated specification so a five-minute analysis of its loss tolerance is not really possible, but I presume they thought of it. A quick read of RFC 2057 section 3.3 seems to imply that IPHC can amplify loss with high rates of context change, but I have no idea how this actually works or does not work in practice. The point is that the point will have to be addressed, either by ensuring that all header compression is relatively loss tolerant for common CC-induced loss rates, or by using lower-layer tricks to segregate TCM from TCP traffic.

This is definitely content for the applicability statement, and the ability to meet these goals for a given use case should be a criteria for determining whether or not that use case is in or out of scope for TCMTF.

>> And we'd really more input from vendors already building boxes in this
>> space, and operators deploying them, as input to scoping and
> applicability.
> We have some messages in the list:

Indications of interest are great. Contributions to eventual documents are even better. :)