Hi all, As you may know, we are thinking about presenting a BOF proposal for IETF 87 in Berlin (July-August), with the aim of creating a Working Group.
I have prepared a presentation about TCMTF, in order to show some figures with the scenarios, the protocol stack, and some of the obtained bandwidth savings (for some cases, they are about 70%). The presentation can be found here: http://diec.unizar.es/~jsaldana/personal/ietf/tcmtf_2013.pdf The draft of the charter is here: http://diec.unizar.es/~jsaldana/personal/ietf/tcmtf_charter_draft.pdf , and also in this message: http://www.ietf.org/mail-archive/web/tcmtf/current/msg00191.html The mailing list we are using for preparing the BOF is tc...@ietf.org (https://www.ietf.org/mailman/listinfo/tcmtf) If you have any suggestions for improvement, they will be welcome. Best regards, Jose Saldana -----Mensaje original----- De: tsv-area-boun...@ietf.org [mailto:tsv-area-boun...@ietf.org] En nombre de Jose Saldana Enviado el: miércoles, 30 de enero de 2013 18:21 Para: tsv-area@ietf.org; tc...@ietf.org CC: Gonzalo Camarillo; Martin Stiemerling Asunto: About the possibility of having a BOF about TCMTF in IETF87 Hi all. With this e-mail I would like to socialize TCMTF (Tunneling, Compressing and Multiplexing Traffic Flows) within the IETF. We have the idea of presenting a BOF proposal for IETF 87 in Berlin (July-August), with the aim of creating a Working Group. In this message I will talk about the problem we are trying to solve, and I will try to summarize the story of TCMTF within the IETF. - The main idea (see also the Charter proposal below) is to define a method for saving bandwidth in real-time services which use tiny packets. Some examples of these services are online games, viceoconference, in addition to VoIP. The overhead of the packets of these services is significant, so the efficiency can be increased when a number of flows share the same path: packets belonging to different flows can be grouped together, adding a small multiplexing delay as a counterpart. Currently, there exists an efficiency improvement method for VoIP using RTP: RFC4170 (TCRTP). It considers header compression by means of ECRTP; multiplexing by means of PPPMux; and tunneling by means of L2TPv3. However, in the last years, emerging real-time services which do not use UDP/RTP protocols have become popular: some of them use UDP or even TCP. In addition, new header compression methods have been defined (ROHC). So widening the scope of RFC4170 in order to consider not only UDP/RTP but also other protocols is seen as convenient. The same three layers would be used: header compression, multiplexing and end-to-end tunneling. Some examples of the scenarios where grouping packets is possible are: aggregation networks of a network operator; a tunnel between two premises 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; etc. - The story: * A first draft was written with cooperation of some people from Transport and RAI Areas. Dan Wing, one of the authors of RFC4170, is also participating on TCMTF from the very beginning. This is the first version (Feb 2012) http://tools.ietf.org/id/draft-saldana-tsvwg-tcmtf-00.txt * It was presented in the TSVWG session (Transport Area) IETF-83, Paris, March 27th 2012: http://www.ietf.org/proceedings/83/minutes/minutes-83-tsvwg.txt. The presentation is here: http://diec.unizar.es/~jsaldana/personal/present-saldana-tsvwg-tcmtf_v2.pdf * A specific mailing list was created (July 10th 2012): https://www.ietf.org/mailman/listinfo/tcmtf * A second draft was submitted (Dec 12th 2012), " Maximum Tolerable Delays when using Tunneling Compressed Multiplexed Traffic Flows": http://datatracker.ietf.org/doc/draft-suznjevic-tsvwg-mtd-tcmtf/ * This is the current version of the initial draft: https://datatracker.ietf.org/doc/draft-saldana-tsvwg-tcmtf/. The number of authors and contributors has been increased. - Many people have participated in the mailing list, mainly from network operators, network equipment manufacturers, a Space Agency (DLR) and Academia. - And finally, this is the current version of the Charter Proposal. We have discussed and polished it in the list (http://www.ietf.org/mail-archive/web/tcmtf/current/threads.html), and we have arrived to this agreement: *Description of Working Group v4* 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 using wireless or satellite scenarios). 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; a tunnel between two premises 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; etc. 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. 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 (A) 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 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 that each extreme implements at each level, and in the scenario. So document (A) will also include a negotiation mechanism to decide the options to use 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. 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 (B) with useful recommendations in order to decide which packet flows can or can not be multiplexed and how. The document (B) 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. 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 protocol stack (A) and signaling mechanisms. Recommendations (B) of using existing traffic classification methods, maximum delay and jitter to add, depending on the service. ------------------ Thank you very much, Jose Saldana > -----Mensaje original----- > De: tcmtf-boun...@ietf.org [mailto:tcmtf-boun...@ietf.org] En nombre > de Martin Stiemerling Enviado el: martes, 29 de enero de 2013 12:54 > Para: jsald...@unizar.es > CC: w...@mti-systems.com; tc...@ietf.org; > gonzalo.camari...@ericsson.com > Asunto: Re: [tcmtf] Improved version of the TCMTF Charter proposal > (v3) > > Hi Jose, > > On 01/29/2013 11:57 AM, Jose Saldana wrote: > > Yes, Martin. The idea is that many interested people may attend IETF > > Berlin in July: at least I know about interested people from U. > > Zaragoza, DLR, Telefonica, U. Zagreb, U. Stuttgart, who could attend > > that BoF. And also co-authors from Cisco (Dan, Michael, and perhaps > > Muthu) may be there. Well, these are the news I have. In addition, > > Mirko and I would also be able to organize the "online games traffic tutorial > there". > > So Berlin is the place to make a BoF. > > > > > So is your idea to have a BoF for discussing the TCMTF WG in Berlin? > > Do you prefer that possibility instead of the "DISPATCH" option that > > Gonzalo suggested? If you confirm that, we would take it into > > account in order to organize the summer calendar. > > We do not have the DISPATCH option in the Transport Area. > > My proposal is to start socializing the idea within the IETF and to > aim for a BoF > in Berlin. Sending the proposal to the TSVAREA list might be a good start. > > Martin > > > > > Thanks a lot, > > > > Jose > > PS: This is the option that Gonzalo suggested to Wes (November 29th): > > "Hi Wes, > > > > sure. When the proponents have a charter proposal ready, feel free > > to send it to the TSVAREA list for comments while informing all the > > other lists. If you want, I can take care of informing the DISPATCH > > list pointing to the relevant message in the TSVAREA list when you send it. > > > > With respect to where discussions should take place, DISPATCH > > participants will find it easier to send comments on the DISPATCH list. > > However, if sending comments requires subscribing to a different > > list and sending comments to a different crowd, many may not bother > > commenting. I can monitor the discussions in DISPATCH and send you a > > summary if needed. Since we are talking about very few lists, it > > should be relatively easy to keep things under control. > > > > Cheers, > > > > Gonzalo" > >> -----Mensaje original----- > >> De: tcmtf-boun...@ietf.org [mailto:tcmtf-boun...@ietf.org] En > >> nombre de Martin Stiemerling Enviado el: martes, 29 de enero de > >> 2013 11:39 > >> Para: FERNANDO PASCUAL BLANCO > >> CC: w...@mti-systems.com; tc...@ietf.org; matteo.beri...@dlr.de; > >> gonzalo.camari...@ericsson.com; jsald...@unizar.es > >> Asunto: Re: [tcmtf] Improved version of the TCMTF Charter proposal > >> (v3) > >> > >> Hi all, > >> > >> The BoF deadline for the upcoming meeting was Jan 28. > >> > >> Further, my understanding is the relevant proponents cannot make it > >> to the IETF meeting in March in Orlando, but that there is a plan > >> for the IETF meeting in Berlin in July 2013. > >> > >> Martin > >> > >> On 01/29/2013 11:13 AM, FERNANDO PASCUAL BLANCO wrote: > >>> Hi all, > >>> > >>> In my opinion the WG is needed. TCMTF discussion have > >>> reach enough interest and enough roadmap to have a room for > >>> itself, at least an small room. As Jose said, there are two enough > >>> active drafts and there is potentially room for three more, and I > >>> think this is a justification by itself. > >>> On the other hand, I also think that we are problem centered. > >>> At least being in a network operation feet I find TCMTF useful enough. > >>> > >>> Regards, > >>> > >>> Fernando Pascual Blanco > >>> Telefónica Global Resources > >>> Network Automation and Dynamization TECHNOLOGY PEOPLE GROUP F > >>> +34913128779 M +34682005168 f...@tid.es > >>> > >>> > >>> > >>> > >>> On 29/01/13 10:56, "Jose Saldana" <jsald...@unizar.es> wrote: > >>> > >>>> Matteo, > >>>> > >>>> Thanks a lot. Well, in this case, I don't agree with you (only in > >>>> this case). > >>>> > >>>> The idea with TCMTF was to create a "small" Working Group, the > >>>> same way as they are created in other Areas (e.g. RAI). > >>>> > >>>> As Wes said in November, " In my opinion, it is something a > >>>> separate WG should be created to handle, and not something to try > >>>> to do inside the TSVWG, since there are already a handful of > >>>> things TSVWG is wrestling with, and it creates too much "context > >>>> switching" to have a lot of unrelated topics under work there." > >>>> > >>>> The question is that the TSVWG group has a lot of interesting > >>>> things now, and it would be better to discuss TCMTF separately. > >>>> In fact, since the Summer, we are discussing it in another > >>>> mailing list. This is good, but in fact many people from TSVWG > >>>> have not followed our > >> discussion. > >>>> > >>>> In addition, a lot of time has passed. TCMTF draft was presented > >>>> in Paris > >>>> 10 > >>>> months ago. A lot of people from many institutions have become > >>>> interested on it. We have two drafts and three more possibilities. > >>>> > >>>> Neither am I an expert on IETF, but I understand that things have > >>>> some > >>>> "momentum": if you let time go by, people may lose their interest. > >>>> And curently interest does exist, as we have seen in the list. So > >>>> why > > not > >> now? > >>>> > >>>> In addition, the new version of the Charter is more > >>>> problem-centered (I hope). > >>>> > >>>> Thanks and best regards, > >>>> > >>>> Jose > >>>> > >>>> > >>>>> -----Mensaje original----- > >>>>> De: tcmtf-boun...@ietf.org [mailto:tcmtf-boun...@ietf.org] En > >> nombre > >>>>> de matteo.beri...@dlr.de Enviado el: martes, 29 de enero de 2013 > >>>>> 9:18 > >>>>> Para: w...@mti-systems.com; jsald...@unizar.es > >>>>> CC: tc...@ietf.org; gonzalo.camari...@ericsson.com; > >>>>> martin.stiemerl...@neclab.eu > >>>>> Asunto: Re: [tcmtf] Improved version of the TCMTF Charter > >>>>> proposal > >>>>> (v3) > >>>>> > >>>>> Dear all, > >>>>> > >>>>> I don't have a huge experience in IETF, but feel it is important > >>>>> to > >>>> express my > >>>>> opinion this time. > >>>>> I have the feeling building a new WG is a bit premature, > >>>>> considering that > >>>> we > >>>>> just have an Internet draft. > >>>>> I also find the discussion a bit documents-driven, rather than > >>>>> problems- driven. > >>>>> IMHO we could wait a bit, before creating the WG, to see whether > >>>>> the ideas we have really solve real-world problems. > >>>>> > >>>>> That's it. Hope this helps. > >>>>> > >>>>> Matteo > >>>>> > >>>>> > >>>>> -----Original Message----- > >>>>> From: tcmtf-boun...@ietf.org [mailto:tcmtf-boun...@ietf.org] On > >>>>> Behalf Of Wesley Eddy > >>>>> Sent: 24 January 2013 06:16 > >>>>> To: jsald...@unizar.es > >>>>> Cc: tc...@ietf.org; Gonzalo Camarillo; Martin Stiemerling > >>>>> Subject: Re: [tcmtf] Improved version of the TCMTF Charter > >>>>> proposal > >>>>> (v3) > >>>>> > >>>>> On 1/23/2013 6:58 AM, Jose Saldana 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. > >>>>>> > >>>>>> ... > >>>>> > >>>>> > >>>>> In my opinion, this is decent, though here are two criticisms: > >>>>> > >>>>> (1) In my opinion, it focuses too much on documents to be produced, > >>>>> rather than fully and clearly motivating why the working group > >>>>> is needed (i.e. to solve a problem, not to develop documents), > >>>>> how it's scope is delimited (i.e. what it *won't* touch isn't > >>>>> clear to me, along with what other areas/WGs need to be > >>>>> coordinated with), and what the end-goal is. > >>>>> > >>>>> (2) There's a focus on defining technical solutions prior to the > >>>>> mention of fleshing out and totally defining the use cases / > >>>>> requirements. In my opinion, that appears backwards :). > >>>>> > >>>>> That said, I'm generally supportive of this work. In my > >>>>> opinion, as an > >>>> AD, we > >>>>> would normally feel better having a BoF before forming a WG, for > >>>>> two reasons (1) to get other areas (e.g. RAI) to be aware of > >>>>> what's being proposed, and (2) to vet that there really is a > >>>>> community of stakeholders that are engaged to do the work. In > >>>>> this case, I think the 2nd point is evident from the mailing > >>>>> list, and I don't have a concern about it at all. > >>>> I > >>>>> think the 1st point can be addressed through the responsible AD > >>>>> coordinating with the IESG and the directorates or area mailing > >>>>> lists that related areas have. > >>>>> Since I'm going away as an AD though, what really matters at the > >>>>> moment is what Martin thinks :). > >>>>> > >>>>> -- > >>>>> Wes Eddy > >>>>> MTI Systems > >>>>> _______________________________________________ > >>>>> tcmtf mailing list > >>>>> tc...@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/tcmtf > >>>>> _______________________________________________ > >>>>> tcmtf mailing list > >>>>> tc...@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/tcmtf > >>>> > >>>> _______________________________________________ > >>>> tcmtf mailing list > >>>> tc...@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/tcmtf > >>> > >>> > >>> ________________________________ > >>> > >>> Este mensaje se dirige exclusivamente a su destinatario. Puede > >>> consultar > >> nuestra política de envío y recepción de correo electrónico en el > >> enlace situado más abajo. > >>> This message is intended exclusively for its addressee. We only > >>> send and > >> receive email on the basis of the terms set out at: > >>> http://www.tid.es/ES/PAGINAS/disclaimer.aspx > >>> > >> > >> -- > >> martin.stiemerl...@neclab.eu > >> > >> NEC Laboratories Europe - Network Research Division NEC Europe > >> Limited Registered Office: NEC House, 1 Victoria Road, London W3 > >> 6BL Registered in England 283 > >> _______________________________________________ > >> tcmtf mailing list > >> tc...@ietf.org > >> https://www.ietf.org/mailman/listinfo/tcmtf > > > > -- > martin.stiemerl...@neclab.eu > > NEC Laboratories Europe - Network Research Division NEC Europe Limited > Registered Office: NEC House, 1 Victoria Road, London W3 6BL > Registered in England 283 > _______________________________________________ > tcmtf mailing list > tc...@ietf.org > https://www.ietf.org/mailman/listinfo/tcmtf
