[tcmtf] TCMTF Charter proposal (v4)

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

According to the suggestions of Wes, Matteo and Mirko, I have built this new
version. The explaining is in the previous mail Do you like it?

 

Thanks a lot,

 

Jose

------------------------------

 

*Description of Working Group v4*

 

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
to the other extreme of the communication. Therefore, its overhead is
significant, and it becomes even higher when IPv6 is used, since the basic
IPv6 header is twice the size of the IPv4 one. 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).

 

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; a tunnel between two premises 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
satellite connection used for collecting the data of a high number of
sensors; etc.

 

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 or even TCP. 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 or even TCP), 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 multiplexer can build a bigger packet in which a number of
payloads share a common header. A demultiplexer 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 (TCMTF). 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 (A) 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 multiplexer/de- multiplexer want to establish a tunnel, 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 document (A) will also include a negotiation mechanism to
decide the options to use at each layer (header compression, multiplexing
and tunneling) between multiplexer and de-multiplexer, and a mechanism to
setup/release a tunnel between a multiplexer and a de-multiplexer.

 

8. As a counterpart of the bandwidth saving, TCMTF 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 (B) with useful recommendations in order to decide
which packet flows can or can not be multiplexed and how. The document (B)
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.

 

9. If other interesting features are identified, the group would re-charter
and include them, e.g., a mechanism for a multiplexer to discover a
de-multiplexer, and vice versa; a mechanism to select an optimal multiplexer
and a de-multiplexer when there are more than one muxer/de-muxer for a flow;
dynamically applying TCMTF: a higher entity in charge of deciding when and
where, applying or not TCMTF, and what kind of TCMTF, and what multiplexing
period. Additional methods for estimating delay would also be required.

 

10. In addition, specific uses of TCMTF, such as in wireless and satellite
scenarios, could be considered, and it will be studied whether modifications
or extensions are required on the protocol.

 

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

 

*Goals and Milestones*

 

Specification of TCMTF protocol stack (A) and signaling mechanisms.

 

Recommendations (B) of using existing traffic classification methods,
maximum delay and jitter to add, depending on the service.