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

From: "Jose Saldana" <[email-masked]>
Date: Thu, 13 Jun 2013 10:37:51 +0200

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

---

From: "Jose Saldana" <[email-masked]>
Date: Thu, 13 Jun 2013 10:43:05 +0200

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: [email-masked] [mailto:[email-masked]] En nombre de
> Jose Saldana
> Enviado el: jueves, 13 de junio de 2013 10:38
> Para: [email-masked]; [email-masked]
> Asunto: [tcmtf] Improved version of the tmctf Draft charter (v6)
> 
that
> use the Internet for the delivery of interactive multimedia
> 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.
> 
> 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:
> 
> - an agreement between two network operators could allow them to
> compress a number of flows they are exchanging between a pair of Internet
> Routers;
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,
> 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:
> 
> 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
> 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.
> 
> 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:
> compression, multiplexing and tunneling) between multiplexer and de-
> multiplexer,
> 
delay.
> However, regarding delay-sensitive services, the Working Group will also
> develop a document (TCMTF - recommendations) with useful
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.
> 
> 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
> 
> _______________________________________________
> tcmtf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcmtf

---

From: Julián Fernández-Navajas <[email-masked]>
Date: Fri, 14 Jun 2013 10:45:10 +0200

Jose and Gorry and all,
In order to clarify the delay-sensitive application term, i think that 
there are more than two options: sensitive and nonsensitive. I'd prefer 
say delay-very-sensitive's application, delay-sensitive, 
delay-some-sensitive, delay-nonsensitive or something similar
Julián

---

From: FERNANDO PASCUAL BLANCO <[email-masked]>
Date: Fri, 14 Jun 2013 19:28:38 +0000

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 +34913128779
M +34682005168
[email-masked]

On 13/06/13 10:43, "Jose Saldana" <[email-masked]> wrote:

>in order to say that ³For both the delay-sensitive and delay-insensitive
>applications, their small data payloads incur significant overhead²
>
>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².
>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
>TCP flows) will also have to be addressed.²
>
>Jose
>
>
>> 2. The efficiency cannot be increased by the inclusion of a higher
>>number
>of

________________________________

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

---

From: "Jose Saldana" <[email-masked]>
Date: Mon, 17 Jun 2013 09:31:49 +0200

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

> De: FERNANDO PASCUAL BLANCO [mailto:[email-masked]]
> Enviado el: viernes, 14 de junio de 2013 21:29
> Para: [email-masked]; [email-masked]; [email-masked]
> Asunto: Re: [tcmtf] Improved version of the tmctf Draft charter (v6)
> 
> Hi Jose,
> 
>         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)
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?
> 
> >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²
> >
> >6. I have changed the name of the document: instead of ³document A² it
> >is now ³TCMTF  reference model².
> >
> >eventual impact of multiplexing on protocol dynamics (e.g. when
> >multiplexing TCP flows) will also have to be addressed.²
> >
> >Jose
> >
> >
> >> De: [email-masked] [mailto:[email-masked]] En nombre
> >> de Jose Saldana Enviado el: jueves, 13 de junio de 2013 10:38
> >> 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-
> >> 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:
> >>
> >> - 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;
> >>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.
> >>
> >>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
> >>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
> >> - 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
> >> - 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
> >>standard protocols are being used at each layer, the signaling methods
> >>of  those protocols will be used. Interactions with the Working Groups
> >>and
> >Areas
> >>development of new compressing, multiplexing or tunneling protocols is
> >>not  an objective of this Working Group. In addition, since the
> >>current RFC
> >4170
> >> by the interaction between layers will have to be issued, and
> >> 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
> >> 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:
> >> 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
> >>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
> >> service or application. The eventual impact of multiplexing on
> >>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
> >>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
> >> 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
> >>
> >>classification methods, maximum delay and jitter to add, depending on
> >>the  service.
> >>
> >>
> 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:

---

From: Julián Fernández-Navajas <[email-masked]>
Date: Mon, 17 Jun 2013 11:02:23 +0200

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

---

From: FERNANDO PASCUAL BLANCO <[email-masked]>
Date: Mon, 17 Jun 2013 09:12:17 +0000

Hi Jose, Julian,

        Yes, "TCM optimizers" and "TCM flow" are perfect for me too.

Best,

Fernando Pascual Blanco

On 17/06/13 11:02, "Julián Fernández-Navajas" <[email-masked]> wrote:

>>>          Nevertheless I wanted to mention, after read carefully the
>>>text,
>> that
>>>          But in paragraph 8 we talk about multiplexing flows and the
>>>impact
>> of
>>>>> they use in each layer: header compression, multiplexing and
>>>>>tunneling.
>>>> This

---

From: José Ruiz <[email-masked]>
Date: Mon, 17 Jun 2013 12:37:26 +0200

Hi all,

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

Pepe

---

From: José Ruiz <[email-masked]>
Date: Mon, 17 Jun 2013 12:39:07 +0200

Hi all,

Pepe

---

From: "Diego R. Lopez" <[email-masked]>
Date: Mon, 17 Jun 2013 13:39:35 +0000

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,

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/

e-mail: [email-masked]
Tel:    +34 913 129 041
Mobile: +34 682 051 091
-----------------------------------------

---

From: Mirko Sužnjević <[email-masked]>
Date: Wed, 26 Jun 2013 08:35:26 +0000

I am maybe a little late, but i agree with this terminology.
Mirko

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of José Ruiz
Sent: Monday, June 17, 2013 12:39 PM
To: [email-masked]
Subject: Re: [tcmtf] Improved version of the tmctf Draft charter (v6)

Hi all,

Pepe

El 17/06/2013 11:12, FERNANDO PASCUAL BLANCO escribió:
>> In relation with duplicating flow word, i think that it is fine to 
>> use "TCM flow" instead of "TCMTF flow".
>> Julián
>>
>>> "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
>>>
>>>