Re: [tcmtf] Glossary of TCMTF terms

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

Excellent work, Mirko and Jose
A suggestion, in the policy manager definition is used the term TCMTF 
multiplexers and demultiplexers, perhaps would be better to use 
TCMTF-optimizer term.
Thanks
Julián

El 18/06/2013 13:04, Jose Saldana escribió:
> Hi,
>
> Mirko and I included an "index term" at the beginning of the TCMTF -
> recommendations draft. Perhaps we could consider the possibility of also
> including one TCMTF - reference model draft.
>
> Here go some definition proposals, which can of course be improved:
>
> TCM-optimizer / TCMTF-optimizer
>
>     The host where TCM optimization (also TCMTF optimization) is deployed.
> It corresponds to both  the
>     ingress and the egress of the tunnel where native packets are included.
>
>     If the optimizer  compresses headers, multiplexes packets and creates the
> tunnel, it behaves as a "TCM-ingress optimizer".
>    
>     If it decompresses headers, demultiplexes packets and extracts packets
> from the tunnel, it behaves as a "TCM-egress optimizer".
>
> policy manager
>
>     A network entity which makes the decisions about TCMTF parameters:
>     multiplexing period; flows to be multiplexed together, depending on
>     their IP addresses, ports, etc.  It is connected with a number of
>     TCMTF multiplexers and demultiplexers, and orchestrates the
>     optimization that takes place between them.
>
> native packet
>
>     A packet sent by an application, belonging to a flow that can be
>     optimized by means of TCMTF.
>
> native flow
>
>     A flow of native packets.
>
> TCM packet / optimized packet / TCM-optimized packet
>
>     A packet including a number of multiplexed and header-compressed
>     native ones, and also a tunneling header.
>
> TCM flow / optimized flow / TCM-optimized flow
>
>     A flow of TCM packets.
>
>
> Best regards,
>
> Jose
>
>> -----Mensaje original-----
>> De: [e-mail] [mailto:[e-mail]] En nombre de
>> Diego R. Lopez
>> Enviado el: lunes, 17 de junio de 2013 15:40
>> Para: <[e-mail]>
>> CC: <[e-mail]>; <[e-mail]>; FERNANDO PASCUAL BLANCO
>> Asunto: Re: [tcmtf] Improved version of the tmctf Draft charter (v6)
>>
>> Hi Jose,
>>
>> I like your latter proposal. TCM-* should be enough: TCMTF technology is
>> provided (and leveraged) by TCM-* elements.
>>
>> Only a comment on your first statement: we *can* invent new English verbs.
>> English does not have stupid institutions like our Academy, but this is a
>> completely different discussion...
>>
>> Be goode,
>>
>> On 17 Jun 2013, at 09:31 , Jose Saldana wrote:
>>
>>> 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.p
>>>>>> df
>>>>>>
>>>>>>
>>>>>> 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
>>
>> --
>> "Esta vez no fallaremos, Doctor Infierno"
>>
>> Dr Diego R. Lopez
>> Telefonica I+D
>> http://people.tid.es/diego.lopez/
>>
>> e-mail: [e-mail]
>> Tel:    [phone]
>> Mobile: [phone]
>> -----------------------------------------
>>
>>
>> ________________________________
>>
>> 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
>
>