[tcmtf] Glossary of TCMTF terms

["Jose Saldana" <[e-mail]>]

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