[tcmtf] Next version (v11) of TCM-TF charter draft

"Jose Saldana" <jsaldana@unizar.es> Wed, 15 January 2014 09:47 UTC

Return-Path: <jsaldana@unizar.es>
X-Original-To: tcmtf@ietfa.amsl.com
Delivered-To: tcmtf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 97C5F1ADBD1; Wed, 15 Jan 2014 01:47:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.024
X-Spam-Status: No, score=-4.024 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, ONE_TIME=0.714, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id nGYqbEJXm0X6; Wed, 15 Jan 2014 01:47:02 -0800 (PST)
Received: from huecha.unizar.es (huecha.unizar.es []) by ietfa.amsl.com (Postfix) with ESMTP id 4AB541ADF88; Wed, 15 Jan 2014 01:47:01 -0800 (PST)
Received: from usuarioPC (gtc1pc12.cps.unizar.es []) by huecha.unizar.es (8.13.8/8.13.8/Debian-3) with ESMTP id s0F9kfZJ011143; Wed, 15 Jan 2014 10:46:41 +0100
From: "Jose Saldana" <jsaldana@unizar.es>
To: <tsv-area@ietf.org>, <tcmtf@ietf.org>
Date: Wed, 15 Jan 2014 10:46:52 +0100
Message-ID: <0a5c01cf11d6$b7f08320$27d18960$@unizar.es>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0A5D_01CF11DF.19B64AB0"
X-Mailer: Microsoft Outlook 14.0
Content-language: es
Thread-index: Ac8R1lQ09Tz0qQTzQqu6k/HdxtLbAg==
X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter
Cc: Martin Stiemerling <mls.ietf@gmail.com>
Subject: [tcmtf] Next version (v11) of TCM-TF charter draft
X-BeenThere: tcmtf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Tunneling Compressed Multiplexed Traffic Flows \(TCMTF\) discussion list" <tcmtf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcmtf>, <mailto:tcmtf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcmtf/>
List-Post: <mailto:tcmtf@ietf.org>
List-Help: <mailto:tcmtf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcmtf>, <mailto:tcmtf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Jan 2014 09:47:05 -0000

According to the comments of David, I have moved the signaling sentences
from 5 to 7, and merged the rest of 5 with 6. So this is the new version
(Thanks again, David!):
Tunneling Compressed Multiplexed Traffic Flows (TCM-TF) charter draft v11
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,
* 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. 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. 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. Since standard protocols are being considered 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. Taking into account that different options will be considered when
a pair of TCM-TF optimizers want to establish a session, they will 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
* 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 .
7. 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.
8. 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.
9. Interactions with other Working Groups can be expected, since TCM-TF uses
already defined protocols for compression, multiplexing and tunneling (ROHC,
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
Current version of Document (TCM-TF - reference model):
Current version of Document (TCM-TF - recommendations):