Re: [tcmtf] Improved version of the tmctf Draft charter (v6)

[José Ruiz <[e-mail]>]

Hi all,

I agree with you. "TCM optimizers" and "TCM flow" would be enough,

Pepe

El 17/06/2013 11:12, FERNANDO PASCUAL BLANCO escribió:
> Hi Jose, Julian,
>
>          Yes, "TCM optimizers" and "TCM flow" are perfect for me too.
>
> Best,
>
> Fernando Pascual Blanco
> Telefónica Global Resources
> Network Automation and Dynamization
> TECHNOLOGY PEOPLE GROUP
> F [phone]
> M [phone]
> [e-mail]
>
>
>
>
> On 17/06/13 11:02, "Julián Fernández-Navajas" <[e-mail]> wrote:
>
>> I agree with Fernando too, no invent new English verb.
>> In relation with duplicating flow word, i think that it is fine to use
>> "TCM flow" instead of "TCMTF flow".
>> Julián
>>
>> El 17/06/2013 9:31, Jose Saldana escribió:
>>> Hi, Fernando.
>>>
>>> I agree with you. We are talking about standards so precision is
>>> important.
>>>
>>> I don't think we should use the "verb" "to TCMTF" nor "TCMTFing" nor
>>> "TCMTFed". We cannot invent new English verbs.
>>>
>>> What about "optimization"?. This concept summarizes the three layers.
>>> We can
>>> use it this way:
>>>
>>> - A TCMTF optimizer
>>>
>>> - A packet optimized by means of TCMTF
>>> - A flow optimized by means of TCMTF
>>> - An optimized packet
>>> - An optimized flow
>>> - A TCMTF-optimized packet
>>> - A TCMTF-optimized flow
>>> - A TCMTF packet
>>> - A TCMTF flow
>>>
>>> - the TCMTF optimization can be applied to that flow
>>> - the impact of TCMTF optimization on protocol dynamics
>>>
>>> I have another question here: could we use only TCM instead of TCMTF?
>>> Remember that TF means "traffic flows", so a TCMTF flow would be a
>>> "tunneling compressed multiplexed traffic flows flow". Perhaps a TCM
>>> flow
>>> would be enough in those cases. TCM does not have another related
>>> meaning
>>> and it is shorter than TCMTF (http://www.acronymfinder.com/TCM.html)
>>>
>>> - A TCM optimizer
>>> - A TCM-optimized flow
>>> - A TCM flow
>>>
>>> What do you think?
>>>
>>> Jose
>>>
>>>> -----Mensaje original-----
>>>> De: FERNANDO PASCUAL BLANCO [mailto:[e-mail]]
>>>> Enviado el: viernes, 14 de junio de 2013 21:29
>>>> Para: [e-mail]; [e-mail]; [e-mail]
>>>> Asunto: Re: [tcmtf] Improved version of the tmctf Draft charter (v6)
>>>>
>>>> Hi Jose,
>>>>
>>>>           I like all your changes, they all enrich the WG description.
>>>>
>>>>           Nevertheless I wanted to mention, after read carefully the
>>>> text,
>>> that
>>>> when we talk about layers, we always use the three terms (tunneling,
>>>> multiplexing and compression) and I think it is ok.
>>>>           When we talk about the elements in charge of apply the TCMTF
>>> protocol
>>>> we have call them multiplexers and demultiplexers, and that may be a
>>> little
>>>> confusing, given that they use the name of the middle protocol layer,
>>>> but
>>> I
>>>> understand that we have not found a better name (I include myself here)
>>>> and maybe multiplexing is the most representative layer, so it could be
>>> ok.
>>>>           But in paragraph 8 we talk about multiplexing flows and the
>>>> impact
>>> of
>>>> multiplexing in protocol dynamics, and I think that may be confusing,
>>> given
>>>> that using "multiplexing" we are referring to apply the whole TCMTF
>>> protocol
>>>> or not and not only to apply the multiplexing layer or not. I´m just
>>> saying that
>>>> this term here may be confusing and someone could get a bad
>>>> interpretation
>>>> from the text. I see three option: a) we pre-define the term
>>> "multiplexing"
>>>> as the application of the TCMTF protocol itself, b) we invent the verb
>>>> "to
>>>> TCMTF" and use the participle "TCMTFed" when something is passed trough
>>>> our protocol stack or c) (and maybe the most convenient we use the long
>>>> form "the TCMTF protocol can be applied to that flow" or "the impact of
>>>> TCMTF protocol on protocol dynamics". My suggestion is to use option
>>>> c).
>>>>
>>>>           What do you think?
>>>>
>>>>           Thank you for your great effort!
>>>>
>>>> Best,
>>>>
>>>> Fernando Pascual Blanco
>>>> Telefónica Global Resources
>>>> Network Automation and Dynamization
>>>> TECHNOLOGY PEOPLE GROUP
>>>> F [phone]
>>>> M [phone]
>>>> [e-mail]
>>>>
>>>>
>>>>
>>>>
>>>> On 13/06/13 10:43, "Jose Saldana" <[e-mail]> wrote:
>>>>
>>>>> These are the main changes included in the draft charter v6 (ordered
>>>>> by
>>>>> paragraphs):
>>>>>
>>>>> 1. I have moved the sentence about the overhead to the end of the
>>>>> paragraph, in order to say that ³For both the delay-sensitive and
>>>>> delay-insensitive applications, their small data payloads incur
>>>>> significant overhead²
>>>>>
>>>>> 2. I have put the scenarios in bullets, and I have improved some of
>>>>> the
>>>>> descriptions a bit.
>>>>>
>>>>> 6. I have changed the name of the document: instead of ³document A² it
>>>>> is now ³TCMTF ­ reference model².
>>>>>
>>>>> 7. Now we are talking about another document ³TCMTF ­ negotiation
>>>>> protocol².
>>>>> In addition, I have put the two signaling functionalities in bullets.
>>>>>
>>>>> 7. As discussed in the list, we would talk about ³setup/release a
>>>>> TCMTF
>>>>> session².
>>>>>
>>>>> 8. I have changed the name of the document, from ³document B² to
>>>> ³TCMTF
>>>>> recommendations²
>>>>>
>>>>> 8. According to Gorry¹s suggestion, I have added this sentence: ³The
>>>>> eventual impact of multiplexing on protocol dynamics (e.g. when
>>>>> multiplexing TCP flows) will also have to be addressed.²
>>>>>
>>>>> Jose
>>>>>
>>>>>
>>>>>> -----Mensaje original-----
>>>>>> De: [e-mail] [mailto:[e-mail]] En nombre
>>>>>> de Jose Saldana Enviado el: jueves, 13 de junio de 2013 10:38
>>>>>> Para: [e-mail]; [e-mail]
>>>>>> Asunto: [tcmtf] Improved version of the tmctf Draft charter (v6)
>>>>>>
>>>>>> This is the new proposal, adapted to the new distribution of the
>>>>> documents.
>>>>>> I explain the changes in another e-mail.
>>>>>> It is also here, in a formatted version:
>>>>>> http://diec.unizar.es/~jsaldana/personal/ietf/tcmtf_charter_draft.pdf
>>>>>>
>>>>>>
>>>>>> TCMTF charter draft v6
>>>>>>
>>>>>> Description of Working Group
>>>>>>
>>>>>> 1. In the last years we are witnessing the raise of new real-time
>>>>>> services
>>>>> that
>>>>>> use the Internet for the delivery of interactive multimedia
>>>>>> applications: VoIP, videoconferencing, telemedicine, video vigilance,
>>>>> online
>>>>>> gaming, etc. Due to the need of interactivity, many of these services
>>>>>> use  small packets (some tens of bytes), since they have to send
>>>>>> frequent  updates between the extremes of the communication. In
>>>>>> addition, some  other services also send small packets, but they are
>>>>>> not delay-sensitive
>>>>> (e.g.,
>>>>>> instant messaging, m2m packets sending collected data in sensor
>>>>>> networks using wireless or satellite scenarios). For both the
>>>>>> delay-sensitive and
>>>>> delay-
>>>>>> insensitive applications, their small data payloads incur significant
>>>>> overhead,
>>>>>> and it becomes even higher when IPv6 is used, since the basic IPv6
>>>>>> header
>>>>> is
>>>>>> twice the size of the IPv4 one.
>>>>>>
>>>>>> 2. The efficiency cannot be increased by the inclusion of a higher
>>>>>> number
>>>>> of
>>>>>> samples in a single packet, since this would harm the delay
>>>>>> requirements
>>>>> of
>>>>>> the service. But there exist some scenarios in which a number of
>>>>>> flows
>>>>> share
>>>>>> the same path. In this case, packets belonging to different flows can
>>>>>> be grouped together, adding a small multiplexing delay as a
>>>>>> counterpart of bandwidth saving. This delay will have to be
>>>>>> maintained under some threshold in order to grant the delay
>>>>>> requirements. Some examples of the scenarios where grouping packets
>>>>>> is
>>>> possible are:
>>>>>> - aggregation networks of a network operator;
>>>>>> - an end-to-end tunnel between appliances located in two different
>>>>>> offices  of the same company;
>>>>>> - the access connection of an Internet Café including a high number
>>>>>> of  VoIP/gaming flows;
>>>>>> - an agreement between two network operators could allow them to
>>>>>> compress a number of flows they are exchanging between a pair of
>>>>>> Internet  Routers;
>>>>>> - a satellite connection used for collecting the data of a high
>>>>>> number of  sensors.
>>>>>>
>>>>>> 3. VoIP using RTP is a clear example of a real-time service using
>>>>>> small
>>>>> packets
>>>>>> with high overhead. In order to improve efficiency, RFC4170 (TCRTP)
>>>>> defined
>>>>>> a method for grouping packets when a number of flows share a path,
>>>>>> considering three different layers: header compression by means of
>>>>>> ECRTP;  multiplexing by means of PPPMux; tunneling by means of
>>>>>> L2TPv3.
>>>>>>
>>>>>> 4. However, in the last years, emerging real-time services which do
>>>>>> not
>>>>> use
>>>>>> UDP/RTP have become popular: some of them use UDP or even TCP. In
>>>>>> addition, new header compression methods have been defined (ROHC).
>>>> So
>>>>>> there is a need of widening the scope of RFC4170 in order to consider
>>>>>> not  only UDP/RTP but also other protocols. The same structure of
>>>>>> three layers  will be considered:
>>>>>>
>>>>>> - Header compression: Taking into account that real-time applications
>>>>>> use  different headers (RTP/UDP, UDP or even TCP), different
>>>>>> protocols
>>>>>> can be
>>>>>> used: no compression, ECRTP, IPHC and ROHC.
>>>>>> - Multiplexing: If a number of flows share a path between an origin
>>>>>> and a  destination, a multiplexer can build a bigger packet in which
>>>>>> a
>>>>>> number of  payloads share a common header. A demultiplexer is then
>>>>>> necessary at the  end of the common path, so as to rebuild the
>>>>>> packets
>>>>>> as they were
>>>>> originally
>>>>>> sent. PPPMux will be the main option. Other ones are not discarded.
>>>>>> - Tunneling will be used to send the multiplexed packets end-to-end.
>>>>>> The options in this layer are L2TP, GRE and MPLS.
>>>>>>
>>>>>> 5. So the first objective of this group is to specify the protocol
>>>>>> stack
>>>>> for
>>>>>> tunneling, compressing and multiplexing traffic flows (TCMTF). Since
>>>>>> standard protocols are being used at each layer, the signaling
>>>>>> methods
>>>>>> of  those protocols will be used. Interactions with the Working
>>>>>> Groups
>>>>>> and
>>>>> Areas
>>>>>> in which these protocols are developed can be expected. However, the
>>>>>> development of new compressing, multiplexing or tunneling protocols
>>>>>> is
>>>>>> not  an objective of this Working Group. In addition, since the
>>>>>> current RFC
>>>>> 4170
>>>>>> would be considered as one of the options, this RFC could be
>>>>>> obsoleted.
>>>>>>
>>>>>> 6. As a first objective, a document (TCMTF - reference model) will
>>>>>> define
>>>>> the
>>>>>> different options which can be used at each layer. Specific problems
>>>>> caused
>>>>>> by the interaction between layers will have to be issued, and
>>>>>> suitable extensions may have to be added to the involved protocols.
>>>>>>
>>>>>> 7. If a pair multiplexer/de-multiplexer want to establish a TCMTF
>>>>>> session,  they have first to use a mechanism to negotiate which
>>>>>> concrete option
>>>>> would
>>>>>> they use in each layer: header compression, multiplexing and
>>>>>> tunneling.
>>>>> This
>>>>>> will depend on the protocols that each extreme implements at each
>>>>>> level, and in the scenario. So another document (TCMTF - negotiation
>>>>>> protocol)
>>>>> will
>>>>>> include:
>>>>>>
>>>>>> - a mechanism to setup/release a TCMTF session between a multiplexer
>>>>>> and a de-multiplexer, also including:
>>>>>> - a negotiation mechanism to decide the options to use at each layer
>>>>> (header
>>>>>> compression, multiplexing and tunneling) between multiplexer and de-
>>>>>> multiplexer,
>>>>>>
>>>>>> 8. As a counterpart of the bandwidth saving, TCMTF may add some delay
>>>>>> and  jitter. This is not a problem for the services which are not
>>>>>> sensitive to
>>>>> delay.
>>>>>> However, regarding delay-sensitive services, the Working Group will
>>>>>> also  develop a document (TCMTF - recommendations) with useful
>>>>>> recommendations in order to decide which packet flows can or can not
>>>>>> be  multiplexed and how. The document will present a list of
>>>>>> available
>>>>>> traffic  classification methods which can be used for identification
>>>>>> of the service
>>>>> or
>>>>>> application to which a particular flow belongs, as well as
>>>>>> recommendations
>>>>> of
>>>>>> the maximum delay and jitter to be added depending of the identified
>>>>>> service or application. The eventual impact of multiplexing on
>>>>>> protocol dynamics (e.g., when multiplexing TCP flows) will also have
>>>>>> to be
>>>>> addressed.
>>>>>> 9. If other interesting features are identified, the group would
>>>>> re-charter and
>>>>>> include them, e.g., a mechanism for a multiplexer to discover a de-
>>>>>> multiplexer, and vice versa; a mechanism to select an optimal
>>>>>> multiplexer  and a de-multiplexer when there are more than one
>>>>>> muxer/de-muxer for a  flow; dynamically applying TCMTF: a higher
>>>>>> entity in charge of deciding
>>>>> when
>>>>>> and where, applying or not TCMTF, and what kind of TCMTF, and what
>>>>>> multiplexing period. Additional methods for estimating delay would
>>>>>> also be  required.
>>>>>>
>>>>>> 10. In addition, specific uses of TCMTF, such as in wireless and
>>>>>> satellite  scenarios, could be considered, and it will be studied
>>>>>> whether
>>>>> modifications
>>>>>> or extensions are required on the protocol.
>>>>>>
>>>>>> 11. Interactions with other Working Groups can be expected, since
>>>>>> TCMTF  uses already defined protocols for compression, multiplexing
>>>>>> and tunneling  (ROHC, PPPMux, MPLS, GRE, L2TP).
>>>>>>
>>>>>> Goals and Milestones
>>>>>>
>>>>>> Specification of TCMTF  reference model.
>>>>>>
>>>>>> Specification of TCMTF negotiation protocol.
>>>>>>
>>>>>> Specification of TCMTF recommendations of using existing traffic
>>>>>> classification methods, maximum delay and jitter to add, depending on
>>>>>> the  service.
>>>>>>
>>>>>>
>>>>>> Current version of Document (TCMTF - reference model):
>>>>>> https://datatracker.ietf.org/doc/draft-saldana-tsvwg-tcmtf/
>>>>>>
>>>>>> Current version of Document (TCMTF - recommendations):
>>>>>> http://datatracker.ietf.org/doc/draft-suznjevic-tsvwg-mtd-tcmtf/
>>>>>>
>>>>>>
>>>>>> Best regards,
>>>>>>
>>>>>> Jose
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> tcmtf mailing list
>>>>>> [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
>>> _______________________________________________
>>> 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
> _______________________________________________
> tcmtf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcmtf
>
>