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

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

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 multimedia
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 IPv6
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 flows.
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 (TCRTP)
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 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. 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 4170
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 modifications/extensions.

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):
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/



Best regards,

Jose