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

"Jose Saldana" <> Thu, 13 March 2014 11:03 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id B5A611A09D6 for <>; Thu, 13 Mar 2014 04:03:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.748
X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ZOp4nSQQZBl0 for <>; Thu, 13 Mar 2014 04:03:44 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 943DA1A09D4 for <>; Thu, 13 Mar 2014 04:03:43 -0700 (PDT)
Received: from usuarioPC ( []) by (8.13.8/8.13.8/Debian-3) with ESMTP id s2DB3W4f027813; Thu, 13 Mar 2014 12:03:32 +0100
From: "Jose Saldana" <>
To: "'Brian Trammell'" <>
References: <> <> <008301cf3dcc$52b8f6f0$f82ae4d0$> <>
In-Reply-To: <>
Date: Thu, 13 Mar 2014 12:03:35 +0100
Message-ID: <012301cf3eab$e153d0d0$a3fb7270$>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQHzuOG1bU6Xk0Mlov/nfhNUFohXjwJwnHIaAX1/GgoCmveixpphmEzA
Content-Language: es
X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter
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: Thu, 13 Mar 2014 11:03:49 -0000

Thanks, Brian!

I will send a new charter in five minutes including these things:
modifications in n. 3, 5 and milestones; a new n.8.

Comments inline.

> -----Mensaje original-----
> De: tcmtf [] En nombre de Brian Trammell
> Enviado el: miércoles, 12 de marzo de 2014 10:00
> Para: Jose Saldana
> CC:; Martin Stiemerling; Spencer Dawkins
> Asunto: Re: [tcmtf] Thank you for a great BoF!
> 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.
> making it explicit (i.e., ensuring the phrase "backward compatible with
> 4170" appears in the charter text) fixes this problem.
> <snip>

I have modified points 3, 5 and milestones so as to maintain backwards
compatibility with RFC4170.

> >> 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
> 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
> (necessary for the operation of loss-based congestion control) on all
> sharing the bottleneck link.
> This is a key point to account for when running TCP and TCM across the
> 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
> 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
> context change, but I have no idea how this actually works or does not
> in practice. The point is that the point will have to be addressed, either
> ensuring that all header compression is relatively loss tolerant for
> CC-induced loss rates, or by using lower-layer tricks to segregate TCM
> TCP traffic.

The objective of ROHC was to build a "robust" header compression mechanism,
i.e. robust against context desynchronization. So the main idea is that it
can work over lossy links, much better than older header compression
mechanisms (ECRTP, IPHC). So we could perhaps suggest that the loss rate has
to be taken into account during the negotiation of the header compression
protocol to be used. I mean:

- If we are considering a congested link, or a wireless link, ROHC can be
the best choice.
- If the link is not too congested, or it is wired (very low packet loss
rate), other options can be considered, since they present less
computational requirements.

We could add this text to the charter. Something like this:

8. The TCM-TF – recommendations document will also provide information about
the best suited header compression protocol for each scenario. When traffic
is being compressed over a lossy link (wireless, high amount of background
traffic, etc.), an algorithm with better robustness against context
desynchronization (i.e. ROHC) will be desirable; however, if compression is
being deployed in a link presenting a low packet loss rate (dedicated links,
wired scenarios), simpler algorithms (i.e. IPHC, ECRTP) can be used, since
they present less processing requirements.

> 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. :)
> Cheers,
> Brian