Re: [tcmtf] Next version (v10) of TCM-TF charter draft

"Black, David" <> Wed, 08 January 2014 14:34 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 10B001AE3D8; Wed, 8 Jan 2014 06:34:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.824
X-Spam-Status: No, score=-1.824 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, ONE_TIME=0.714, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id z9lijvikoFey; Wed, 8 Jan 2014 06:34:12 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 90F961AE3C1; Wed, 8 Jan 2014 06:34:00 -0800 (PST)
Received: from ( []) by (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s08EXklQ029135 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Jan 2014 09:33:48 -0500
X-DKIM: OpenDKIM Filter v2.4.3 s08EXklQ029135
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed;; s=jan2013; t=1389191628; bh=QIQsRoEUiSNSwTbHjPy+sLtfDNE=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=HlTm7k0ZBqINjkCiSrm6VMKBpb5bbHCihEqkToPnmIM6EC7AJfvFHn2Sm2RmrAqTL IBqZbZ5T6gGDPz+LiKMEPhdrX1lrK0xviXTZ2lclb/3xqQKUnlEDpNeeOs4Hhe8BOE dxfIAVUjEqYaDe3IB3EcL9MKy39RdIHgufTpR9Lk=
X-DKIM: OpenDKIM Filter v2.4.3 s08EXklQ029135
Received: from ( []) by (RSA Interceptor); Wed, 8 Jan 2014 09:33:28 -0500
Received: from ( []) by (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s08EXR3c013868 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 8 Jan 2014 09:33:28 -0500
Received: from ([]) by ([]) with mapi; Wed, 8 Jan 2014 09:33:27 -0500
From: "Black, David" <>
To: Jose Saldana <>, "" <>, "" <>
Date: Wed, 8 Jan 2014 09:33:26 -0500
Thread-Topic: Next version (v10) of TCM-TF charter draft
Thread-Index: Ac8MUTJEFfBaeFLER7ezjsW9Se+pLwALH/ig
Message-ID: <>
References: <001b01cf0c63$ea240b00$be6c2100$>
In-Reply-To: <001b01cf0c63$ea240b00$be6c2100$>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_8D3D17ACE214DC429325B2B98F3AE712026EF3043DMX15Acorpemcc_"
MIME-Version: 1.0
X-RSA-Classifications: DLM_1, public
Cc: Martin Stiemerling <>
Subject: Re: [tcmtf] Next version (v10) of TCM-TF charter draft
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, 08 Jan 2014 14:34:16 -0000


This version is definitely improved.

I would suggest moving the signaling material from paragraph 5 into paragraph 7 so that the existing signaling protocols and the new TCM-TF negotiation protocol (including their intended relationship/interaction) are discussed in one place. The rest of paragraph 5 could then be merged into paragraph 6.

David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786        Mobile: +1 (978) 394-7754

From: tsv-area [] On Behalf Of Jose Saldana
Sent: Wednesday, January 08, 2014 6:22 AM
Cc: Martin Stiemerling
Subject: Next version (v10) of TCM-TF charter draft

Tunneling Compressed Multiplexed Traffic Flows (TCM-TF) charter draft v10

Description of Working Group

1. RFC4170 (TCRTP) defines a method for grouping packets when a number of UDP/RTP VoIP flows share a common path, considering three different layers: ECRTP header compression; PPPMux multiplexing; L2TPv3 tunneling. TCRTP optimizes the traffic, increasing the bandwidth efficiency of VoIP and reduces the amount of packets per second at the same time.

2. However, in the last years, emerging real-time services which use bare UDP instead of UDP/RTP have become popular. Due to the need of interactivity, many of these services use small packets (some tens of bytes). Some other services also send small packets, but they are not delay-sensitive (e.g., instant messaging, m2m packets in sensor networks). In addition, a significant effort has been devoted to the deployment of new header compression methods with improved robustness (ROHC).

3. So there is a need of replacing RFC4170 with an extended solution able to optimize these new flows, also using improved compression methods. The same structure of three layers will be considered:

* Header compression: different protocols can be used: no compression, ECRTP, IPHC and ROHC.
* Multiplexing: PPPMux will be the option.
* Tunneling: the options in this layer are L2TP, GRE and MPLS.

4. New scenarios where bandwidth savings are desirable have been identified, in addition to those considered in RFC4170. In these scenarios, there are moments or places where network capacity gets scarce, so allocating more bandwidth is a possible solution, but it implies a recurring cost. However, the inclusion of a pair of boxes able to optimize the traffic when/where required is a one-time investment. These scenarios can be classified into:

* Multidomain, the TCMT-TF tunnel goes all the way from one network edge to another, and can therefore cross several domains.
* Single Domain, TCM-TF is only activated inside an ISP, from the edge to border inside the network operator.
* Private Solutions. TCM-TF is used to connect private networks geographically apart (e.g. corporation headquarters and subsidiaries), without the ISP being aware or having to manage those flows.
* Mixed Scenarios, any combination of the previous ones.

5. Since standard protocols are being used at each layer, the signaling methods of those protocols will be used. Thus, interactions with the Working Groups and Areas in which these protocols are developed can be expected. However, the development of new compressing, multiplexing or tunneling protocols is not an objective of this Working Group. In addition, since the current RFC 4170 would be considered as one of the options, this RFC would be obsoleted.

6. A first document (TCM-TF - reference model) will define the different options which can be used at each layer. It will include a detailed specification of the scenarios of interest. Specific problems caused by the interaction between layers will have to be issued, and suitable extensions may have to be added to the involved protocols. The impact on other protocols will also be studied.

7. Taking into account that different options will be considered, when a pair of TCM-TF optimizers want to establish a session, they have first to negotiate which concrete option would they use in each layer. This will depend on the protocols that each extreme implements at each level, and in the scenario. So another document (TCM-TF - negotiation protocol) will include:

* a mechanism to setup/release a TCM-TF session between an ingress and an egress-optimizer, also including:
* a negotiation mechanism to decide the options to use at each layer .

8. As a counterpart of the bandwidth saving, TCM-TF may add some delay and jitter. This is not a problem for the services which are not sensitive to delay. However, regarding delay-sensitive services, the Working Group will also develop a document (TCM-TF - recommendations) with useful recommendations in order to decide which packet flows can or can not be multiplexed and how. The document will present a list of available traffic classification methods which can be used for identification of the service or application to which a particular flow belongs, as well as recommendations of the maximum delay and jitter to be added depending of the identified service or application. The eventual impact of multiplexing on protocol dynamics (e.g. the loss of a multiplexed packet, MTU-related issues) will also have to be addressed.

9. The working group may identify additional deliverables that are necessary/useful, e.g., a mechanism for a TCM-ingress optimizer to discover an egress optimizer, and vice versa. The working group would re-charter to add them before working on them.

10. Interactions with other Working Groups can be expected, since TCM-TF uses already defined protocols for compression, multiplexing and tunneling (ROHC, PPPMux, MPLS, GRE, L2TP).

Goals and Milestones

Specification of TCM-TF reference model and the scenarios of interest. This would obsolete RFC4170.

Specification of TCM-TF negotiation protocol.

Specification of TCM-TF recommendations of using existing traffic classification methods, maximum delay and jitter to add, depending on the service.

Current version of Document (TCM-TF - reference model):

Current version of Document (TCM-TF - recommendations):