[tcmtf] New version (v9) of the TCM-TF Charter draft

["Jose Saldana" <[e-mail]>]

TCM-TF charter draft v9

Description of Working Group

1. RFC4170 (TCRTP) defines a method for grouping packets when a number of
RTP VoIP flows share a common path, considering three different layers:
header compression by means of ECRTP; multiplexing by means of PPPMux;
tunneling by means of L2TPv3. VoIP using RTP is a clear example of a
real-time service using small packets with high overhead, where efficiency
can be substantially improved in certain scenarios. As said in RFC4170,
"TCRTP solves the VoIP bandwidth discrepancy, especially for large,
voice-trunking applications."

2. In addition to VoIP, in the last years we are witnessing the raise of new
real-time services that use the Internet for the delivery of interactive
multimedia applications e.g. 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 links). 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 IPv6
header is twice the size of the IPv4 one.

3. In the moments or places where network capacity gets scarce, 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
(reducing bandwidth and packets per second) when/where required is a
one-time investment. Thus, in scenarios including a bottleneck with a single
Layer-3 hop, header compression algorithms (e.g. ROHC) can be used for
reducing the overhead of each flow, at the cost of additional processing.
However, if header compression is to be deployed in a network path including
several Layer-3 hops, tunneling can be used in order to allow the
header-compressed packets to travel end-to-end, thus avoiding the need to
compress and decompress at each intermediate node. In these cases,
compressed packets belonging to different flows can be multiplexed together,
in order to share the tunnel overhead. In this case, a small multiplexing
delay will be necessary as a counterpart, in order to join a number of
packets to be sent together. This delay has to be maintained under a
threshold in order to grant the delay requirements.

4. However, in the last years, emerging real-time services which use bare
UDP instead of UDP/RTP have become popular. In addition, a significant
effort has been devoted to the deployment of new header compression methods
with improved robustness (ROHC). So there is a need of widening the scope of
RFC4170 in order to consider these new header compression methods, and also
UDP in addition to UDP/RTP. The same structure of three layers will be
considered:

* 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. Furthermore, new scenarios where bandwidth savings are desirable, in
addition to those considered in RFC4170, have been identified. This is a
classification:

* Multidomain, in the sense the TCMT-TF tunnel 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 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. As an
example, an end-to-end tunnel between appliances located in two different
offices of the same company. In some cases the tunnel is already included
for security reasons. Another example can be a shared wireless Internet in a
place with low Internet penetration. This can happen in a community network
(typically deployed in rural areas or in developing countries), in which a
number of people in the same geographical place share their connections in a
cooperative way, and a number of wireless hops are required in order to
reach a router connected to the Internet;

* Mixed Scenarios, any combination of the previous scenarios.

6. As a result, the next objectives can be achieved:

* Significant bandwidth reductions (as an example, bandwidth savings of 55%
can be obtained for VoIP if IPv4 is used, and 65% using IPv6. For certain
online games, 33% of the bandwidth can be saved for IPv4, and 55% when using
IPv6).

* A reduction of the amount of packets per second managed by the network. A
reduction factor of 10 or 20 can easily be achieved. This can be translated
into smaller processing delays and energy savings in intermediate routers.

7. So the main 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. 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 could be obsoleted.

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

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

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

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

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

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):
https://datatracker.ietf.org/doc/draft-saldana-tsvwg-tcmtf/

Current version of Document (TCM-TF - recommendations):
http://datatracker.ietf.org/doc/draft-suznjevic-tsvwg-mtd-tcmtf/