Re: [tcmtf] TCMTF-Feedback about a possible BoF in London

"Jose Saldana" <> Thu, 09 January 2014 00:11 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 3B81F1ACCEC; Wed, 8 Jan 2014 16:11:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.738
X-Spam-Status: No, score=-4.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id HE97BzjnAT92; Wed, 8 Jan 2014 16:11:48 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 8A1C91ADEA7; Wed, 8 Jan 2014 16:11:41 -0800 (PST)
Received: from jsaldanapc ([]) (authenticated bits=0) by (8.13.8/8.13.8/Debian-3) with ESMTP id s090B1fQ014219; Thu, 9 Jan 2014 01:11:08 +0100
From: "Jose Saldana" <>
To: "'Black, David'" <>, <>, <>, "Luigi Iannone" <>
References: <00c401cefd65$6e8ef570$4bace050$> <>
In-Reply-To: <>
Date: Thu, 9 Jan 2014 01:10:48 +0100
Message-ID: <004701cf0ccf$4d5826a0$e80873e0$>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0048_01CF0CD7.AF212280"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQKm4iuy1T4jUNWcvPCI8e0mPkHF7QHB3wddmLzCScA=
Content-Language: es
X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter
Cc: 'Martin Stiemerling' <>
Subject: Re: [tcmtf] TCMTF-Feedback about a possible BoF in London
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, 09 Jan 2014 00:11:53 -0000

Hi all.


First of all, thanks to David and Luigi for their valuable comments.


I will wait for a while in order to include David’s comments (perhaps some
other people has more suggestions).


These are the improvements of version 10 with respect to v9 (


- I have shortened paragraph 1.

- I have shortened and merged paragraphs 2 and 3.

- I have moved paragraph 4 to the third place, in order to set clearer what
we want: replacing RFC4170 with a widened proposal. As David suggested, I
have also shortened the text and it is now more straightforward.

- I have clearly stated which protocols will be used on each layer. The
negotiation mechanism is still necessary, since different options are
considered e.g. for header compression. The one to be used will depend on
the scenario and the processing capacity of the two optimizers.

- I have significantly shortened the description of the scenarios.

- I have removed paragraph 6, which included the savings figures.

- I have included the replacement of RFC4170 in the first milestone.






De: Black, David [ <>] 
Enviado el: sábado, 04 de enero de 2014 4:05
Para: Jose Saldana;  <>;
CC: Martin Stiemerling; Black, David
Asunto: RE: TCMTF-Feedback about a possible BoF in London


A second BoF has the explicit goal of forming a WG, as a third BoF

is not permitted.  In that regard, the new charter seems long and

somewhat lacking in focus.  Two key things I look for in a proposed

charter are what problem (or problems) the proposed WG is looking to

solve and an initial approach to the problem or problems.


In the new draft charter, the problem statement appears to be in

paragraph 4 with paragraph 1 providing important background.  The

focus of the work appears to be on extending TCRTP (RFC 4170) to

UDP and to include new compression protocols.  In contrast, I have

a hard time discerning the initial approach from the new draft charter.


In light of this, there are a few things that I wish the new

draft charter had definitive proposals for:


      a) Whether to replace RFC 4170 vs. write a new RFC (could be

            UDP-only or UDP + RTP/UDP) as a complement to RFC 4170.

      b) Whether to use ECRTP, ROHCv2 (RFC 5225) and/or IPHC (RFC 2507 ?).

            Non-use of ECRTP would be a major change to 4170, and I

wonder about IPHC, as opposed to the ROHCv2 profiles.

      c) Analogies to b) for the Mux and Tunnel layers of the stack.


Overall, it looks like the first task of the WG is to select the protocol

stack to standardize - I have misgivings about that, and would prefer to

see a concrete proposal in a crisp charter that ran along the following

lines, naming the protocols to be used:


1) RFC 4170 does X, and needs the following changes/additions: X, Y, Z.

2) The WG will replace RFC 4170 with a new RFC that contains: A, B, C.


A specific proposal or proposals for the protocol stack or stacks

would also narrow the scope of item 9 in the charter on the negotiation

mechanism.  I also don’t see a goal/milestone listed for an extension to

or replacement for RFC 4170.


I’d prefer to see a much shorter more focused draft charter.  There’s a

bunch of background material that does not seem crucial to the charter,

starting w/paragraphs 2 and 3.




From: tsv-area [ <>] On Behalf Of Jose Saldana
Sent: Friday, December 20, 2013 4:26 AM
To:  <>;  <>
Cc: Martin Stiemerling
Subject: TCMTF-Feedback about a possible BoF in London


Hi all,


After the feedback received in the BoF in Berlin, we have updated the TCM-TF
charter and the two drafts. We have tried to solve all the problems raised
during the session.


Our plan is to request a new BoF in London next March, so we would like to
know your opinion about these two questions:



1.  Is the new, reduced scope of TCM-TF suitable to form a working group?



2. We would like to kindly ask people who think that a TCM-TF Working group
should be formed, to come forward and send an e-mail to the
<>  mailing list stating it.



This feedback will allow us to get a better idea of the convenience of a


The new charter is here:

This is the old one (presented in Berlin):


In these links you can see the differences between the new versions of the
drafts and the old ones:





The main improvements are:


- TCP optimization has been removed

- The classification of the scenarios has been refined and improved. Some of
them have been removed

- A section about energy consumption has been added to the main draft

- A reference to the potential problem of the MTU and packet loss has been

- The problem of the added delays is studied in detail in the second draft


- The improvements of the charter are summarized here:



Best regards,