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

[Luigi Iannone <[e-mail]>]

Hi,

On 23 Jan. 2013, at 12:58 , Jose Saldana <[e-mail]> wrote:

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

For the sake of planning, let's consider document (E) as a discussion item when re-chartering.

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

Looks good to me.

Luigi


>  
> 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
>  
> _______________________________________________
> tcmtf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcmtf