Re: [tcmtf] Improved version (v8) of the TCM-TF charter draft

DAVID FLOREZ RODRIGUEZ <> Fri, 22 November 2013 11:04 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 8207A1ACCF0; Fri, 22 Nov 2013 03:04:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.727
X-Spam-Status: No, score=-4.727 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.525, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id sPc5nDvS7Hnk; Fri, 22 Nov 2013 03:04:11 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id AFF1E1AC828; Fri, 22 Nov 2013 03:04:09 -0800 (PST)
Received: from sbrightmailg02.hi.inet (Sbrightmailg02.hi.inet []) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0MWN009HCW2PK5@tid.hi.inet>; Fri, 22 Nov 2013 12:04:01 +0100 (MET)
Received: from vanvan (vanvan.hi.inet []) by sbrightmailg02.hi.inet (Symantec Messaging Gateway) with SMTP id C1.46.28420.12A3F825; Fri, 22 Nov 2013 12:04:01 +0100 (CET)
Received: from (mailhost.hi.inet []) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0MWN009H0W2OK5@tid.hi.inet>; Fri, 22 Nov 2013 12:04:01 +0100 (MET)
Received: from EX10-MB1-MAD.hi.inet ([]) by EX10-HTCAS5-MAD.hi.inet ([::1]) with mapi id 14.03.0158.001; Fri, 22 Nov 2013 12:04:00 +0100
Date: Fri, 22 Nov 2013 11:03:59 +0000
In-reply-to: <>
X-Originating-IP: []
To: "Reinaldo Penno (repenno)" <>, "" <>, "" <>, "" <>
Message-id: <DB1D666A7A799C4EA9B8D31FFB919BB252F796D8@EX10-MB1-MAD.hi.inet>
MIME-version: 1.0
Content-type: text/plain; charset=iso-8859-1
Content-language: es-ES
Content-transfer-encoding: quoted-printable
Accept-Language: es-ES, en-US
Thread-topic: [tcmtf] Improved version (v8) of the TCM-TF charter draft
Thread-index: Ac7l26JNd/G0n/QzTnmgW1GPEao+ugAM6JKAAFhn73A=
X-AuditID: 0a5f4e69-b7fe58e000006f04-5a-528f3a216eec
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrELMWRmVeSWpSXmKPExsXCFe9nqKto1R9kcPKnsMWuzxsYLRa8Wczs wOSxZMlPpgDGKC6blNSczLLUIn27BK6M881GBQsTK5Y172BqYFwT0MXIySEhYCIxadpUFghb TOLCvfVsXYxcHEIC2xgl7u0+yQThPGWU6D7xgAmkSkhgJqPE6VlpIDaLgKrEqY07weJsAroS 8/bMBpskLOAm0fbqN1icU0BP4mtLHyvEBgWJP+ces4AMFRFYyyhxZe1fsCJmgVSJ9oVb2UFs XgFviYmXVzFC2IISPybfY4Go0ZHo/f6NGcIWl5jzayIrhK0t8eTdBTCbUUBWYuX500C9HEAL 3CUWrjYFCYsIWEkc+H2GGeIGAYkle85D2aISLx//Y4X4K1pix8rrbBMYxWch2TwLyeZZSDbP QrJ5ASPLKkax4qSizPSMktzEzJx0AyO9jEy9zLzUkk2MkHjK3MG4fKfKIUYBDkYlHt6dln1B QqyJZcWVuYcYJTiYlUR4/6n2BwnxpiRWVqUW5ccXleakFh9iZOLglGpgNODc1ji50fnFvEJ7 +xXz3rX6cfXOi9F30/PddaR47zbe+qzG30UHOp/PX1l4865+5NsHe94af7r66Ky2qO6lts/3 pqy4NeOlwtmik32MzbGTcqe88Z2gVnPEj9/m4mWNPJYlj0+y87WULZFRP/vnibjwD6bvt/9z f01/8Gj1MqOAldudH/RrpiqxFGckGmoxFxUnAgAGGNcNhQIAAA==
References: <008c01cee5e1$9caa4590$d5fed0b0$> <>
Cc: Martin Stiemerling <>, 'Spencer Dawkins' <>
Subject: Re: [tcmtf] Improved version (v8) of the 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: Fri, 22 Nov 2013 11:04:15 -0000


Just to add my two cents to the "use case" controversy.

>From the point of view of the network the way we envisage the TCM-TF ingress/egress optimisers' deployment could be as follows.

* Multidomain, in the sense the TCMT-TF goes all the way from one network edge to another, and therefore can cross several domains. Note that this is not from border to border (which could be covered with specialized links) but from edge to edge (e.g. managing all traffic from individual users arriving at a Game Provider, regardless users' location)
* Single Domain, so the TCM-TF is only activated inside an ISP, from the edge to border  inside the network operator. The geographical scope and network depth of TCM-TF activation could be on demand, according to traffic conditions
* "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 scenarios.

Best Regards,


David Flórez Rodríguez
Phone: 34+913129618
Backup Phone: 34+913128842
Network Optimisation and Dynamisation Initiative
Telefonica I+D


As if my life were shaven
and fitted to a frame
and could not breathe without a key
and 'twas like midnight, some,
when everything that ticked has stopped
and space stares all around
or grisly frost, first autumn morns,
repeal the beating ground
but most like chaos, stopless, cool
without a chance or spar
or even a report of land
to justify dispair

              Emily Dickinson


-----Mensaje original-----
De: tcmtf [] En nombre de Reinaldo Penno (repenno)
Enviado el: miércoles, 20 de noviembre de 2013 19:41
CC: Martin Stiemerling; 'Spencer Dawkins'
Asunto: Re: [tcmtf] Improved version (v8) of the TCM-TF charter draft


Some comments:

* Put somewhere more explicitly the problem statement. If we are doing this to save bandwidth, then I suggest saying so in one bullet instead of being lost inside a huge paragraph.
* Number 5: "So the first objective of this group². Then number 6 "As a first objective, a document..². There are two first objectives with different descriptions. Are these the same document or different documents?
* "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². My first reaction would be to not try to list available classification methods since it will get into implementation details. And what if traffic is e2e encrypted? Given the whole surveillance thing should we we can expect this to happen? How would you know a flow is candidate or suitable for compression?
* I wonder if some of the possible scenarios really apply. It seems we are throwing everything to see what sticks.  Example: Journalist covering the a cycling competition do not need write their report real time. And if they need to do a interview, it seems to be working well right now, HD and everything.
* "- an agreement between two network operators could allow them to compress a number of flows they are exchanging between a pair of Internet Routers². Not sure compressing flows between peering routers is a good use-case.

On 11/20/13, 3:13 AM, "Jose Saldana" <> wrote:

>TCM-TF charter draft v8
>Description of Working Group
>1. In the last years we are witnessing the raise of new real-time
>services that use the Internet for the delivery of interactive
>applications: VoIP, videoconferencing, telemedicine, video vigilance,
>online gaming, etc. Due to the need of interactivity, many of these
>services use small packets (some tens of bytes), since they have to
>send frequent updates between the extremes of the communication. In
>addition, some other services also send small packets, but they are not
>delay-sensitive (e.g., instant messaging, m2m packets sending collected
>data in sensor networks using wireless or satellite scenarios). For
>both the delay-sensitive and delay-insensitive applications, their
>small data payloads incur significant overhead, and it becomes even
>higher when IPv6 is used, since the basic
>header is twice the size of the IPv4 one.
>2. The efficiency cannot be increased by the inclusion of a higher
>number of samples in a single packet, since this would harm the delay
>requirements of the service. But there exist some scenarios in which a
>number of flows share the same path. In this case, packets belonging to
>different flows can be grouped together, adding a small multiplexing
>delay as a counterpart of bandwidth saving. This delay will have to be
>maintained under some threshold in order to grant the delay
>requirements. Some examples of the scenarios where grouping packets is
>possible are:
>- aggregation networks of a network operator;
>- an end-to-end tunnel between appliances located in two different
>offices of the same company;
>- the access connection of an Internet Café including a high number of
>VoIP/gaming flows;
>- an agreement between two network operators could allow them to
>compress a number of flows they are exchanging between a pair of
>Internet Routers;
>- a wireless Internet connection shared by a number of people in a
>place with low Internet penetration
>- a community network, in which a number of people in the same
>geographical place share their connections in a cooperative way
>- a satellite connection used for collecting the data of a high number
>of sensors.
>- a satellite connection used for providing connectivity in a
>non-connected area during a short period of time (e.g. journalists
>covering the arrival of a mountain stage of a cycling competition).
>- an air-to-ground connection providing Internet connectivity to the
>passengers of an aircraft, multiplexing a number of simultaneous VoIP
>The same can be applied between a cruise ship and a satellite.
>3. VoIP using RTP is a clear example of a real-time service using small
>packets with high overhead. In order to improve efficiency, RFC4170
>defined a method for grouping packets when a number of flows share a
>path, considering three different layers: header compression by means
>of ECRTP; multiplexing by means of PPPMux; tunneling by means of L2TPv3.
>4. However, in the last years, emerging real-time services which do not
>use UDP/RTP have become popular: some of them use UDP. In addition, new
>header compression methods have been defined (ROHC). So there is a need
>of widening the scope of RFC4170 in order to consider not only UDP/RTP
>but also other protocols. The same structure of three layers will be
>- Header compression: Taking into account that real-time applications
>use different headers (RTP/UDP, UDP), different protocols can be used:
>no compression, ECRTP, IPHC and ROHC.
>- Multiplexing: If a number of flows share a path between an origin and
>a destination, a TCM-optimizer (called TCM-ingress optimizer) can build
>a bigger multiplexed packet in which a number of payloads share a
>common header. Another TCM-optimizer (called TCM-egress optimizer) is
>then necessary at the end of the common path, so as to rebuild the
>packets as they were originally sent. PPPMux will be the main option.
>Other ones are not discarded.
>- Tunneling will be used to send the multiplexed packets end-to-end.
>The options in this layer are L2TP, GRE and MPLS.
>5. So the first objective of this group is to specify the protocol
>stack for tunneling, compressing and multiplexing traffic flows
>(TCM-TF). Since standard protocols are being used at each layer, the
>signaling methods of those protocols will be used. 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
>would be considered as one of the options, this RFC could be obsoleted.
>6. As a first objective, a document (TCM-TF - reference model) will
>define the different options which can be used at each layer. 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.
>7. If a pair of ingress/egress optimizers want to establish a TCM-TF
>session, they have first to use a mechanism to negotiate which concrete
>option would they use in each layer: header compression, multiplexing
>and tunneling. 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
>(header compression, multiplexing and tunneling) between an ingress and
>an egress-optimizer,
>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. In addition, specific uses of TCM-TF, such as in wireless and
>satellite scenarios, could be considered, and it might be studied
>whether modifications or extensions are required on the protocol. The
>working group would re-charter to work on those
>11. 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.
>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):
>Best regards,
>tcmtf mailing list

tcmtf mailing list


Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at: