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

From: "Jose Saldana" <[email-masked]>
Date: Fri, 1 Mar 2013 18:05:54 +0100

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: [email-masked] [mailto:[email-masked]] En nombre de
> Jose Saldana
> Enviado el: lunes, 18 de febrero de 2013 9:50
> Para: [email-masked]
> CC: [email-masked]
> 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 [email-masked]
> (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: [email-masked] [mailto:[email-masked]] En
> nombre de Jose Saldana Enviado el: miércoles, 30 de enero de 2013 18:21
> Para: [email-masked]; [email-masked]
> 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: [email-masked] [mailto:[email-masked]] En nombre
> > de Martin Stiemerling Enviado el: martes, 29 de enero de 2013 12:54
> > Para: [email-masked]
> > CC: [email-masked]; [email-masked];
> > [email-masked]
> > 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: [email-masked] [mailto:[email-masked]] En
> > >> nombre de Martin Stiemerling Enviado el: martes, 29 de enero de
> > >> 2013 11:39
> > >> Para: FERNANDO PASCUAL BLANCO
> > >> CC: [email-masked]; [email-masked]; [email-masked];
> > >> [email-masked]; [email-masked]
> > >> 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 [email-masked]
> > >>>
> > >>>
> > >>>
> > >>>
> > >>> On 29/01/13 10:56, "Jose Saldana" <[email-masked]> 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: [email-masked] [mailto:[email-masked]] En
> > >> nombre
> > >>>>> de [email-masked] Enviado el: martes, 29 de enero de 2013
> > >>>>> 9:18
> > >>>>> Para: [email-masked]; [email-masked]
> > >>>>> CC: [email-masked]; [email-masked];
> > >>>>> [email-masked]
> > >>>>> 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: [email-masked] [mailto:[email-masked]] On
> > >>>>> Behalf Of Wesley Eddy
> > >>>>> Sent: 24 January 2013 06:16
> > >>>>> To: [email-masked]
> > >>>>> Cc: [email-masked]; 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
> > >>>>> [email-masked]
> > >>>>> https://www.ietf.org/mailman/listinfo/tcmtf
> > >>>>> _______________________________________________
> > >>>>> tcmtf mailing list
> > >>>>> [email-masked]
> > >>>>> https://www.ietf.org/mailman/listinfo/tcmtf
> > >>>>
> > >>>> _______________________________________________
> > >>>> tcmtf mailing list
> > >>>> [email-masked]
> > >>>> 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
> > >>>
> > >>
> > >> --
> > >> [email-masked]
> > >>
> > >> 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
> > >> [email-masked]
> > >> https://www.ietf.org/mailman/listinfo/tcmtf
> > >
> >
> > --
> > [email-masked]
> >
> > 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
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/tcmtf
> 
> 
> _______________________________________________
> tcmtf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcmtf

---

From: ken carlberg <[email-masked]>
Date: Tue, 5 Mar 2013 11:07:17 -0500

Hola Jose,

Thanks for the expanded explanation, and again, apologies for the tardy repsonse.  Its helpful to understand that document A and B are sequential to each other.  One thing to keep in mind is that if its possible that 2 and 3 (below) can change over time and yet 1 (the reference model) does not, then it may be best to separate 1 from the other items.

as for what you outline as a discussion point for future work, it seems fine.  I just have a personal bias that if you have a clear idea of the things you'd like to accomplish in the future, then having a requirements document would be helpful to focus those thoughts without having to have one particular solution.  But that's a discussion point that could be brought up during the BoF, or sometime afterwards.

cheers,

-ken

> A main document (A) in which we explain the method, the scenarios and the
> minimum signaling issues in order to make it work. The idea is that document
> (A) would be self-contained. Since we are not defining new protocols (i.e.
> already existing compressing, multiplexing and tunneling protocols are to be
> used), we understand that this can be done in a single document. It would
> include:
> 
> 1- Protocol stack (it would be the "reference model")
> 2- a negotiation mechanism to decide the options to use at each layer
> 3- a mechanism to setup/release a tunnel between a multiplexer and a
> de-multiplexer
> 
> Of course, another approach could be separating 1 from 2&3. However, we
> think this is not necessary since the method is not too complicated.
> 
> 
> Document (B) would only contain recommendations of how to better use the
> method proposed in document (A), i.e., classification and maximum delays.
> 
> So clearly document (B) would totally depend on the reference model of
> document (A).
> 
> 
> The idea of point 9 is to talk about some other interesting ideas which are
> considered as "future work":
> - a mechanism for a multiplexer to discover a de-multiplexer
> - 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
> - etc.
> 
> What do you think?
> 
> Thanks again for your feedback. Thinking and explaining things is always a
> good exercise!
> 
> Jose
> 
>> ken carlberg
>> Enviado el: miércoles, 27 de febrero de 2013 16:23
>> Para: [email-masked]
>> CC: [email-masked]; [email-masked]
>> Hola Jose,
>> sorry for the tardy reply.  The altered text below is helpful, thanks.
>> 
>> With respect to your candidate deliverables, it appears that you have
> listed
>> two for the proposed group: (A) a document that describes options and
>> negotiation mechanisms, and (B) a document describing recommendations
>> of which packet types should be multiplexed and a list fo traffic
> classification
>> methods.  Have you considered a third document that presents a more
>> encompassing architecture or framework that would include sample
>> scenarios upon which your deliverables A & B are aimed at?  My impression
> is
>> that you may want to point the reader of documents A & B to the same
>> reference model, and instead of repeating the same text, it may be helpful
>> to separate this into a separate document.
>> 
>> Also, would section 9 of your proposed charter lead one to consider a
>> requirements document?  Many times, new groups start with a
>> requirements document, but since you have a good focus of what you want
>> to accomplish, perhaps your last deliverable could be a requirements
>> document that would guide any future work.
>> 
>> -ken
>> 
>> ps, I don't want to advocate more work, but rather just have you consider
>> other possibilities (and feel free to shoot them down :-)
>> 
>> 
>> On Feb 22, 2013, at 5:39 AM, Jose Saldana <[email-masked]> wrote:
>> 
>>> Hi Ken,
>>> 
>>> Sorry for the delay. I think you are talking about Paragraph 5:
>>> 
>>> 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.
>>> 
>>> Perhaps this is a bit confusing. When we say "at each layer", we are
>>> talking about "tunneling, compressing and multiplexing" layers.
>>> Perhaps this can be a bit confusing. What about this?:
>>> 
>>> 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 for tunneling,
>>> compressing and multiplexing layers, 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.
>>> 
>>> Is this what you were asking?
>>> 
>>> Thanks for your feedback.
>>> 
>>> Jose
>>> 
>>>> de ken carlberg Enviado el: martes, 19 de febrero de 2013 14:17
>>>> Para: [email-masked]
>>>> CC: [email-masked]; [email-masked]
>>>> Hola Jose,
>>>> could you expand a bit more on your text in the proposed charter
>>>> regarding "signaling methods".  Are you speaking in the more general
>>>> context of information stored in headers of various protocol up and
>>>> down the stack
>>> (ie,
>>>> layers 3, 4, and 5/app)?  Or, are you  speaking of concurrent
>>>> resource signaling protocols like RSVP/RSVP-TE, or path establishment
>>>> protocols
>>> like
>>>> MPLS?  Or, some combination of both?
>>>> 
>>>> -ken
>>>>

---

From: "Jose Saldana" <[email-masked]>
Date: Tue, 19 Mar 2013 11:34:24 +0100

Hi all.

I would like to know your feedback (especially from tcmtf co-authors) about
this proposal of Ken:

- Currently, we are thinking about document A including these things:

1) Protocol stack (it would be the "reference model")
2) a negotiation mechanism to decide the options to use at each layer
3) a mechanism to setup/release a tunnel between a multiplexer and a
de-multiplexer

- The proposal of Ken is to split this into two documents:

I, including 1)
II, including 2) and 3)

As Ken says, "One thing to keep in mind is that if it's possible that 2 and
3 (below) can change over time and yet 1 (the reference model) does
not,(...)"

What do you think? Would this complicate or simplify things? Considering the
possibility of having a Working Group, would it be a better approach to
split the problem this way?

Thanks a lot, Ken and everyone!

Jose
 
> De: ken carlberg [mailto:[email-masked]]
> Enviado el: martes, 05 de marzo de 2013 17:07
> Para: [email-masked]
> CC: 'ken carlberg'; [email-masked]; [email-masked]
> Thanks for the expanded explanation, and again, apologies for the tardy
> repsonse.  Its helpful to understand that document A and B are sequential
to
> each other.  One thing to keep in mind is that if its possible that 2 and
3
> (below) can change over time and yet 1 (the reference model) does not,
> then it may be best to separate 1 from the other items.
> 
> as for what you outline as a discussion point for future work, it seems
fine.  I
> just have a personal bias that if you have a clear idea of the things
you'd like
> to accomplish in the future, then having a requirements document would be
> helpful to focus those thoughts without having to have one particular
> solution.  But that's a discussion point that could be brought up during
the
> BoF, or sometime afterwards.
> 
> cheers,
> 
> -ken
> 
> 
> > A main document (A) in which we explain the method, the scenarios and
> > the minimum signaling issues in order to make it work. The idea is
> > that document
> > already existing compressing, multiplexing and tunneling protocols are
> > to be used), we understand that this can be done in a single document.
> > It would
> > include:
> >
> > Of course, another approach could be separating 1 from 2&3. However,
> > we think this is not necessary since the method is not too complicated.
> >
> >
> > Document (B) would only contain recommendations of how to better use
> > the method proposed in document (A), i.e., classification and maximum
> delays.
> >
> > The idea of point 9 is to talk about some other interesting ideas
> > which are considered as "future work":
> > - mechanism to select an optimal multiplexer and a de-multiplexer when
> > there are more than one muxer/de-muxer for a flow
> > Thanks again for your feedback. Thinking and explaining things is
> > always a good exercise!
> >
> > Jose
> >
> >> de ken carlberg Enviado el: miércoles, 27 de febrero de 2013 16:23
> >> Para: [email-masked]
> >> reference model, and instead of repeating the same text, it may be
> >> helpful to separate this into a separate document.
> >>
> >> requirements document, but since you have a good focus of what you
> >> want to accomplish, perhaps your last deliverable could be a
> >> requirements document that would guide any future work.
> >>
> >> -ken
> >>
> >> ps, I don't want to advocate more work, but rather just have you
> >> consider other possibilities (and feel free to shoot them down :-)
> >>
> >>
> >>>> nombre de ken carlberg Enviado el: martes, 19 de febrero de 2013
> >>>> 14:17
> >>>> Para: [email-masked]
> >>>> regarding "signaling methods".  Are you speaking in the more
> >>>> general context of information stored in headers of various
> >>>> protocol up and down the stack
> >>> (ie,
> >>>> resource signaling protocols like RSVP/RSVP-TE, or path
> >>>> establishment protocols
> >>> like

---

From: FERNANDO PASCUAL BLANCO <[email-masked]>
Date: Tue, 19 Mar 2013 17:40:46 +0000

Hi Jose, Ken,

        My thought is that 3 should is very linked with the tunneling layer, so 3
should evolve only if tunnel mechanisms adopted by TCMTF evolve or if
TCMTF adopt new tunneling layers. Because of that, I think that I see 1
together with 3, and define protocol extensions in the future if needed
(BTW, my experience here is very short).
        On the other hand, it is true that 2 could be a different document, but I
remember that it was included to provide a implementation guide to the
protocol itself and bring it to the earth, and not only define TCMTF.
Anyway, I don´t know if 2 mechanisms will evolve so much, a part from the
different capabilities set to be negotiated here.

Regards,

Fernando Pascual Blanco
Telefónica Global Resources
Network Automation and Dynamization
TECHNOLOGY PEOPLE GROUP
F +34913128779
M +34682005168
[email-masked]

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

---

From: MANUEL NUÑEZ SANZ <[email-masked]>
Date: Wed, 20 Mar 2013 10:01:25 +0000

Hi,
    I see the link between 1 and 2, but I also think the negotiation mechanisms in 2 are also very linked with other ones  because you could need some information from the other parts to decide the best options. In brief, I think it is better not split unless the changes  in 2 were a lot in short time.

Regards,
   Manuel.

-----Mensaje original-----
De: [email-masked] [mailto:[email-masked]] En nombre de FERNANDO PASCUAL BLANCO
Enviado el: martes, 19 de marzo de 2013 18:41
Para: [email-masked]; 'ken carlberg'; [email-masked]
CC: [email-masked]
Asunto: Re: [tcmtf] About the possibility of having a BOF about TCMTF in IETF87

Hi Jose, Ken,

        My thought is that 3 should is very linked with the tunneling layer, so 3 should evolve only if tunnel mechanisms adopted by TCMTF evolve or if TCMTF adopt new tunneling layers. Because of that, I think that I see 1 together with 3, and define protocol extensions in the future if needed (BTW, my experience here is very short).
        On the other hand, it is true that 2 could be a different document, but I remember that it was included to provide a implementation guide to the protocol itself and bring it to the earth, and not only define TCMTF.
Anyway, I don´t know if 2 mechanisms will evolve so much, a part from the different capabilities set to be negotiated here.

Regards,

Fernando Pascual Blanco

On 19/03/13 11:34, "Jose Saldana" <[email-masked]> wrote:

>Hi all.
>
>I would like to know your feedback (especially from tcmtf co-authors)
>about this proposal of Ken:
>
>What do you think? Would this complicate or simplify things?
>Considering the possibility of having a Working Group, would it be a
>better approach to split the problem this way?
>
>> De: ken carlberg [mailto:[email-masked]] Enviado el: martes, 05
>> de marzo de 2013 17:07
>> Para: [email-masked]
>> Thanks for the expanded explanation, and again, apologies for the
>>tardy  repsonse.  Its helpful to understand that document A and B are
>>sequential
>to
>> (below) can change over time and yet 1 (the reference model) does
>> not, then it may be best to separate 1 from the other items.
>>
>> to accomplish in the future, then having a requirements document
>>would be  helpful to focus those thoughts without having to have one
>>particular  solution.  But that's a discussion point that could be
>>brought up during
>the
>> > A main document (A) in which we explain the method, the scenarios
>> > and the minimum signaling issues in order to make it work. The idea
>> > is that document
>> > (A) would be self-contained. Since we are not defining new
>> > protocols
>(i.e.
>> > already existing compressing, multiplexing and tunneling protocols
>> > are to be used), we understand that this can be done in a single document.
>> > It would
>> > include:
>> >
>> > 3- a mechanism to setup/release a tunnel between a multiplexer and
>> > a de-multiplexer
>> >
>> > Of course, another approach could be separating 1 from 2&3.
>> > However, we think this is not necessary since the method is not too
>>complicated.
>> >
>> >
>> > Document (B) would only contain recommendations of how to better
>> > use the method proposed in document (A), i.e., classification and
>> > maximum
>> delays.
>> >
>> > So clearly document (B) would totally depend on the reference model
>> > of document (A).
>> >
>> >
>> > - mechanism to select an optimal multiplexer and a de-multiplexer
>> > when there are more than one muxer/de-muxer for a flow
>> >> nombre de ken carlberg Enviado el: miércoles, 27 de febrero de
>> >> 2013 16:23
>> >> Para: [email-masked]
>> >> two for the proposed group: (A) a document that describes options
>> >> and negotiation mechanisms, and (B) a document describing
>> recommendations
>> >> methods.  Have you considered a third document that presents a
>> >> more encompassing architecture or framework that would include
>> >> sample scenarios upon which your deliverables A & B are aimed at?
>> >> My impression
>> > is
>> >> that you may want to point the reader of documents A & B to the
>> >> same reference model, and instead of repeating the same text, it
>> >> may be helpful to separate this into a separate document.
>> >>
>> >> Also, would section 9 of your proposed charter lead one to
>> >> consider a requirements document?  Many times, new groups start
>> >> with a requirements document, but since you have a good focus of
>> >> what you want to accomplish, perhaps your last deliverable could
>> >> be a requirements document that would guide any future work.
>> >>
>> >> -ken
>> >>
>> >>> 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
>> >>> Perhaps this is a bit confusing. When we say "at each layer", we
>> >>> are talking about "tunneling, compressing and multiplexing" layers.
>> >>> 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
>> >>> for tunneling, compressing and multiplexing layers, the signaling
>> >>> methods of those
>> >> protocols will be used.