These are the main changes included in the draft charter v6 (ordered by paragraphs):
1. I have moved the sentence about the overhead to the end of the paragraph, in order to say that For both the delay-sensitive and delay-insensitive applications, their small data payloads incur significant overhead 2. I have put the scenarios in bullets, and I have improved some of the descriptions a bit. 6. I have changed the name of the document: instead of document A it is now TCMTF reference model. 7. Now we are talking about another document TCMTF negotiation protocol. In addition, I have put the two signaling functionalities in bullets. 7. As discussed in the list, we would talk about setup/release a TCMTF session. 8. I have changed the name of the document, from document B to TCMTF recommendations 8. According to Gorrys suggestion, I have added this sentence: The eventual impact of multiplexing on protocol dynamics (e.g. when multiplexing TCP flows) will also have to be addressed. Jose > -----Mensaje original----- > De: tcmtf-boun...@ietf.org [mailto:tcmtf-boun...@ietf.org] En nombre de > Jose Saldana > Enviado el: jueves, 13 de junio de 2013 10:38 > Para: tc...@ietf.org; tsv-area@ietf.org > Asunto: [tcmtf] Improved version of the tmctf Draft charter (v6) > > This is the new proposal, adapted to the new distribution of the documents. > I explain the changes in another e-mail. > It is also here, in a formatted version: > http://diec.unizar.es/~jsaldana/personal/ietf/tcmtf_charter_draft.pdf > > > TCMTF charter draft v6 > > 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 between the extremes of the communication. 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). For both the delay-sensitive and delay- > insensitive applications, their small data payloads incur significant overhead, > and it becomes even higher when IPv6 is used, since the basic IPv6 header is > twice the size of the IPv4 one. > > 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; > - an end-to-end tunnel between appliances located in two different offices > 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. > > 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. In > addition, new header compression methods have been defined (ROHC). 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 (TCMTF - reference model) 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 TCMTF session, > 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 another document (TCMTF - negotiation protocol) will > include: > > - a mechanism to setup/release a TCMTF session between a multiplexer and > a de-multiplexer, also including: > - a negotiation mechanism to decide the options to use at each layer (header > compression, multiplexing and tunneling) between multiplexer and 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 (TCMTF - recommendations) with useful > recommendations in order to decide which packet flows can or can not be > multiplexed and how. The document 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. The eventual impact of multiplexing on protocol > dynamics (e.g., when multiplexing TCP flows) will also have to be addressed. > > 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 reference model. > > Specification of TCMTF negotiation protocol. > > Specification of TCMTF recommendations of using existing traffic > classification methods, maximum delay and jitter to add, depending on the > service. > > > Current version of Document (TCMTF - reference model): > https://datatracker.ietf.org/doc/draft-saldana-tsvwg-tcmtf/ > > Current version of Document (TCMTF - recommendations): > http://datatracker.ietf.org/doc/draft-suznjevic-tsvwg-mtd-tcmtf/ > > > Best regards, > > Jose > > > _______________________________________________ > tcmtf mailing list > tc...@ietf.org > https://www.ietf.org/mailman/listinfo/tcmtf
