[tcmtf] Charter proposal for a possible Working Group about TCMTF

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

Hi all,

 

Since we are considering the possibility of creating a WG for TCMTF, I have
written this Charter. It is only a first version to discuss. In other
messages I will suggest some related questions. So your opinion will now be
really valuable.

 

Document (A) refers to
http://datatracker.ietf.org/doc/draft-saldana-tsvwg-tcmtf/

Document (B) refers to
http://datatracker.ietf.org/doc/draft-suznjevic-tsvwg-mtd-tcmtf/

 

Thanks,

 

Jose

 

 

*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
to the other extreme of the communication. Therefore, its overhead is
significant, and it becomes even worse when IPv6 is used, as 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 mitigate this bad network efficiency, when a number of flows
share a path, packets can be grouped, 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 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 compressing, multiplexing and tunneling
traffic flows. Since only standard protocols are being used, each layer will
use its own signaling methods. Thus, the intended status of this document is
"best current practice". In addition, since it "includes" the current RFC
4170, as one of the options, this RFC would 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 protocols
for any of the layers. Only 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 two mux/demux 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
implementations they include, and in the scenario.

 

6. In addition, TCMTF may save bandwidth but, as a counterpart, some delay
and jitter will be added. 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 recommendations about
the maximum delay and jitter to be added to each kind of service or
application. Empirical research studies with real users will be necessary in
order to establish this set of recommendations.

 

7. If other interesting features are identified, the group would recharter
and include them (e.g., dynamically applying TCMTF: that would be a higher
entity in charge of deciding when and where, applying or not TCMTF, and what
kind of TCMTF, and what multiplexing period, which manly means added delay.
Additional methods for estimating RTT would also be required).

 

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

 

Recommendations of maximum delay depending on the service (B)