Re: [tcmtf] About the possibility of having a BOF about TCMTF in IETF87

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

Hi all,

I have updated the presentation of TCMTF. You may find the new version here:
http://diec.unizar.es/~jsaldana/personal/ietf/tcmtf_2013.pdf

It is not as long as the previous version, since I have passed some slides
to the appendix.

Thanks a lot!

Jose

> -----Mensaje original-----
> De: [e-mail] [mailto:[e-mail]] En nombre de
> Jose Saldana
> Enviado el: lunes, 18 de febrero de 2013 9:50
> Para: [e-mail]
> CC: [e-mail]
> Asunto: Re: [tcmtf] About the possibility of having a BOF about TCMTF in
> IETF87
> 
> 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 [e-mail]
> (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: [e-mail] [mailto:[e-mail]] En
> nombre de Jose Saldana Enviado el: miércoles, 30 de enero de 2013 18:21
> Para: [e-mail]; [e-mail]
> 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: [e-mail] [mailto:[e-mail]] En nombre
> > de Martin Stiemerling Enviado el: martes, 29 de enero de 2013 12:54
> > Para: [e-mail]
> > CC: [e-mail]; [e-mail];
> > [e-mail]
> > 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: [e-mail] [mailto:[e-mail]] En
> > >> nombre de Martin Stiemerling Enviado el: martes, 29 de enero de
> > >> 2013 11:39
> > >> Para: FERNANDO PASCUAL BLANCO
> > >> CC: [e-mail]; [e-mail]; [e-mail];
> > >> [e-mail]; [e-mail]
> > >> 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
> > >>> [phone] M [phone] [e-mail]
> > >>>
> > >>>
> > >>>
> > >>>
> > >>> On 29/01/13 10:56, "Jose Saldana" <[e-mail]> 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: [e-mail] [mailto:[e-mail]] En
> > >> nombre
> > >>>>> de [e-mail] Enviado el: martes, 29 de enero de 2013
> > >>>>> 9:18
> > >>>>> Para: [e-mail]; [e-mail]
> > >>>>> CC: [e-mail]; [e-mail];
> > >>>>> [e-mail]
> > >>>>> 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: [e-mail] [mailto:[e-mail]] On
> > >>>>> Behalf Of Wesley Eddy
> > >>>>> Sent: 24 January 2013 06:16
> > >>>>> To: [e-mail]
> > >>>>> Cc: [e-mail]; 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
> > >>>>> [e-mail]
> > >>>>> https://www.ietf.org/mailman/listinfo/tcmtf
> > >>>>> _______________________________________________
> > >>>>> tcmtf mailing list
> > >>>>> [e-mail]
> > >>>>> https://www.ietf.org/mailman/listinfo/tcmtf
> > >>>>
> > >>>> _______________________________________________
> > >>>> tcmtf mailing list
> > >>>> [e-mail]
> > >>>> 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
> > >>>
> > >>
> > >> --
> > >> [e-mail]
> > >>
> > >> 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
> > >> [e-mail]
> > >> https://www.ietf.org/mailman/listinfo/tcmtf
> > >
> >
> > --
> > [e-mail]
> >
> > 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/tcmtf
> 
> 
> _______________________________________________
> tcmtf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcmtf