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

"Black, David" <> Sat, 04 January 2014 03:05 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 536001AE033; Fri, 3 Jan 2014 19:05:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.538
X-Spam-Status: No, score=-2.538 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wfpgcsz16lUo; Fri, 3 Jan 2014 19:05:29 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 5F7F11AE04A; Fri, 3 Jan 2014 19:05:29 -0800 (PST)
Received: from ( []) by (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s0435ILq009213 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Jan 2014 22:05:19 -0500
X-DKIM: OpenDKIM Filter v2.4.3 s0435ILq009213
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed;; s=jan2013; t=1388804719; bh=4343WqqOrPIjSi3bgycoA21UMss=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=eJk93ynU7WXjZGvW532ocg5acIHPxqu3AawoXE0v9xOhfwsvqehjyTDY0IrG+ol0+ AP/h0SpfmBw1DO4MMh+i1+1Tx8tgdNG+KR7eiyDasdavQQLxAf/nQRmC5JSa2yUYPY IDzI59sZU9BcKEW97bx1ELYu+Bncq+w1kS1GgdK0=
X-DKIM: OpenDKIM Filter v2.4.3 s0435ILq009213
Received: from ( []) by (RSA Interceptor); Fri, 3 Jan 2014 22:05:01 -0500
Received: from ( []) by (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s04350YW015161 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 3 Jan 2014 22:05:01 -0500
Received: from ([]) by ([]) with mapi; Fri, 3 Jan 2014 22:05:00 -0500
From: "Black, David" <>
To: Jose Saldana <>, "" <>, "" <>
Date: Fri, 3 Jan 2014 22:04:58 -0500
Thread-Topic: TCMTF-Feedback about a possible BoF in London
Thread-Index: Ac79ZUO9+o1eWvDOTZW4bKGOX0YCWwLjYMDQ
Message-ID: <>
References: <00c401cefd65$6e8ef570$4bace050$>
In-Reply-To: <00c401cefd65$6e8ef570$4bace050$>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_8D3D17ACE214DC429325B2B98F3AE712026EF2FF8FMX15Acorpemcc_"
MIME-Version: 1.0
X-RSA-Classifications: public
X-Mailman-Approved-At: Sat, 04 Jan 2014 02:45:09 -0800
Cc: Martin Stiemerling <>, "Black, David" <>
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: Sat, 04 Jan 2014 03:05:33 -0000

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

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 added
- The problem of the added delays is studied in detail in the second draft

- The improvements of the charter are summarized here:

Best regards,