[tcmtf] Improved version of the TCMTF Charter proposal (v3)

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

Hello all.

 

After reading the messages in the mailing list, I think we have arrived to a
solution. Each of the documents has been discussed in a separate thread, so
I have tried to take everything into account. Documents (A) and (B) would be
in the Charter. Documents (C) and (D) would only be announced as
possibilities for re-chartering, and Document (E) can wait a little.

 

We can now try to polish this text. If you agree, please report it in the
list.

 

So this is the new charter proposal:

 

*Description of Working Group* v3

 

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

 

2. In order to improve network efficiency, packets can be grouped when a
number of flows share a path, considering three different layers:

- 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 a number of payloads into a single packet. 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.

 

3. So the first objective of this group is to develop a document (A) that
will specify the protocol stack for tunneling, compressing and multiplexing
traffic flows (TCMTF). Since other standard protocols are being used, each
layer will use the signaling methods of those protocols. In addition, since
document (A) would include, as one of the options, the current RFC 4170,
this RFC could be obsoleted.

 

4. The objective of this first document (A) is to define the different
options which can be used at each layer, not the definition of new
compressing, multiplexing or tunneling protocols. 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.

 

5. 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 each of them implements at each level, and in the
scenario. So document (A) will also include a negotiation mechanism to
decide the options 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.

 

6. 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 use of
available traffic classification methods; the maximum delay and jitter to be
added to each kind of service or application. Other recommendations will be
included if necessary. Empirical studies will be necessary in order to
establish this set of recommendations.

 

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

 

8. In addition, specific uses of TCMTF, such as wireless and satellite
scenarios could be considered and addressed if some modifications are
required on the protocol.

 

9. Interactions with other groups can be expected, since TCMTF uses already
defined protocols (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.

 

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

 

Best regards, and thanks for your wonderful work,

 

Jose