Subject: [tcmtf] [TCMTF]: Charter proposal [Fixing subject]

From: "Jose Saldana" <[email-masked]>
Date: Wed, 10 Oct 2012 10:17:23 +0200

Dear all,

As Gonzalo and Mirja suggested, I have written a first draft of the Charter
for a (possible) Working Group about TCMTF. In order to make discussion
easier, I have put a number at the beginning of each paragraph, and I have
denoted the three proposed documents as (A), (B) and (C).

There are two options, in my opinion:

a) Only considering the main draft (A) and the "informational" one (B). If
further documents are necessary, the group could be rechartered. In this
case, paragraph 6 would be a part of paragraph 7. This is the option Mirja
suggested, in order to simplify things (I guess).

b) Considering from the beginning the other options we have talked about.
The question is that some of them are not clear by now.

Wes and Martin: I think your opinions as Area Directors are crucial at this
stage: if you want to start the WG soon, I think option a) would be better.

Of course, I hope more people will participate in the improvement of the
Charter. Your feedback will be greatly appreciated.

Well, here it goes. Best regards,

Jose

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

Description of Working Group (version 0)

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 being generated every second).

2. In order to mitigate this bad network efficiency, when a number of flows
shares 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. 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.

6. Finally, a document (C) for defining a mechanism for negotiating TCMTF
options between multiplexer and demultiplexer should be developed. If two
mux/demux want to establish a tunnel, they have first 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.

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

9. Goals and Milestones

Specification of TCMTF protocol stack (A) Recommendations of maximum delay
depending on the service (B) Mechanism for negotiating TCMTF options between
multiplexer and demultiplexor (C)