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

[Julián Fernández-Navajas <[e-mail]>]

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