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

From: "Jose Saldana" <[email-masked]>
Date: Mon, 18 Feb 2013 09:49:41 +0100

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

---

From: ken carlberg <[email-masked]>
Date: Tue, 19 Feb 2013 08:17:13 -0500

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: Fri, 22 Feb 2013 11:39:16 +0100

Hi Ken,

Sorry for the delay. I think you are talking about Paragraph 5:

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: [email-masked] [mailto:[email-masked]] En nombre de
> ken carlberg
> Enviado el: martes, 19 de febrero de 2013 14:17
> Para: [email-masked]
> CC: [email-masked]; [email-masked]
> Asunto: Re: [tcmtf] About the possibility of having a BOF about TCMTF in
> IETF87
> 
> 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: ken carlberg <[email-masked]>
Date: Wed, 27 Feb 2013 10:23:12 -0500

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

---

From: "Jose Saldana" <[email-masked]>
Date: Thu, 28 Feb 2013 11:33:19 +0100

Thanks, Ken.

The idea is this:

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

> Enviado el: miércoles, 27 de febrero de 2013 16:23
> Para: [email-masked]
> 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 :-)
> 
> 
> > 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.
> >
> >> de ken carlberg Enviado el: martes, 19 de febrero de 2013 14:17
> >> Para: [email-masked]
> >> 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