Subject: [tcmtf] TCMTF BOF description

From: "Jose Saldana" <[email-masked]>
Date: Wed, 5 Jun 2013 13:17:37 +0200

Hi,

I have just built this BOF description for
<http://trac.tools.ietf.org/bof/trac/wiki>
http://trac.tools.ietf.org/bof/trac/wiki. It summarizes the draft charter:

Some emerging interactive services (VoIP, videoconferencing, telemedicine,
video vigilance, online gaming, etc.) use small packets in order to send
frequent updates to the other extreme of the communication. Therefore, its
overhead is significant. In addition, some other services also send small
packets, although they are not delay-sensitive (e.g., instant messaging, m2m
packets sending collected data in sensor networks using wireless or
satellite scenarios).

When a number of small-packet flows share the same path, bandwidth can be
saved by multiplexing packets belonging to different flows, adding a small
multiplexing delay as a counterpart. This delay has 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; a tunnel between two premises of the same company; a
satellite connection used for collecting the data of a high number of
sensors.

RFC4170 <http://tools.ietf.org/html/rfc4170>  (TCRTP) defined a method for
grouping VoIP packets considering three different layers: header compression
by means of ECRTP; multiplexing by means of PPPMux; tunneling by means of
L2TPv3. 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, multiplexing and tunneling.

The BOF aims for the creation of a Working Group in order to specify the
protocol stack, signaling mechanisms and maximum added delay recommendations
for tunneling, compressing and multiplexing traffic flows (TCMTF). 

Do you like it?

Another thing: in the section Relevant I-Ds of the web page, the
"recommendations" draft could also be included:

 <http://datatracker.ietf.org/doc/draft-suznjevic-tsvwg-mtd-tcmtf/>
http://datatracker.ietf.org/doc/draft-suznjevic-tsvwg-mtd-tcmtf/

Best regards,

Jose

---

From: Julián Fernández-Navajas <[email-masked]>
Date: Thu, 06 Jun 2013 10:07:41 +0200

Hi all,
I'd like to make a remark.
I feel that the charter is only oriented to network operator. Perhaps it 
is good strengthen the idea that TCMTF is also beneficial for the 
development of end-to-end aplications.
Julián

El 05/06/2013 13:17, Jose Saldana escribió:
> Some emerging interactive services (VoIP, videoconferencing, 
> telemedicine, video vigilance, online gaming, etc.) use small packets 
> in order to send frequent updates to the other extreme of the 
> communication. Therefore, its overhead is significant. In addition, 
> some other services also send small packets, although they are not 
> delay-sensitive (e.g., instant messaging, m2m packets sending 
> collected data in sensor networks using wireless or satellite scenarios).
>
> When a number of small-packet flows share the same path, bandwidth can 
> be saved by multiplexing packets belonging to different flows, adding 
> a small multiplexing delay as a counterpart. This delay has 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; a tunnel 
> between two premises of the same company; a satellite connection used 
> for collecting the data of a high number of sensors.
>
> RFC4170 <http://tools.ietf.org/html/rfc4170> (TCRTP) defined a method 
> for grouping VoIP packets considering three different layers: header 
> compression by means of ECRTP; multiplexing by means of PPPMux; 
> tunneling by means of L2TPv3. 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, multiplexing and tunneling.
>
> The BOF aims for the creation of a Working Group in order to specify 
> the protocol stack, signaling mechanisms and maximum added delay 
> recommendations for tunneling, compressing and multiplexing traffic 
> flows (TCMTF).
>
> Do you like it?
>
> _______________________________________________
> tcmtf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcmtf

---

From: Martin Stiemerling <[email-masked]>
Date: Thu, 6 Jun 2013 10:56:36 +0200

Hi all,

I have uploaded it to the wiki. The BOF description is now complete.

For your information:
The IAB and the IESG will discuss the BOF proposals on call on June 20th.
The decision whether the BOF proposal is accepted or not is made during 
this call.

   Martin

On 06/05/2013 01:17 PM, Jose Saldana wrote:
> telemedicine, video vigilance, online gaming, etc.) use small packets in
> order to send frequent updates to the other extreme of the
> communication. Therefore, its overhead is significant. In addition, some
> other services also send small packets, although they are not
> delay-sensitive (e.g., instant messaging, m2m packets sending collected
> data in sensor networks using wireless or satellite scenarios).
>
> be saved by multiplexing packets belonging to different flows, adding a
> small multiplexing delay as a counterpart. This delay has to be
> 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, multiplexing and tunneling.
>
> protocol stack, signaling mechanisms and maximum added delay
> “recommendations” draft could also be included:
>

-- 
IETF Transport Area Director

[email-masked]

NEC Laboratories Europe
NEC Europe Limited
Registered Office:
Athene, Odyssey Business Park, West End  Road, London, HA4 6QE, GB
Registered in England 2832014

---

From: "Jose Saldana" <[email-masked]>
Date: Thu, 6 Jun 2013 15:14:35 +0200

Perhaps we could modify the second paragraph, including some bullets for the
scenarios:

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

- a satellite connection used for collecting the data of a high number of
sensors.

Do you like this?

Jose

De: [email-masked] [mailto:[email-masked]] En nombre de
Julián Fernández-Navajas
Enviado el: jueves, 06 de junio de 2013 10:08
Para: [email-masked]
Asunto: Re: [tcmtf] TCMTF BOF description

Hi all,
I'd like to make a remark.
I feel that the charter is only oriented to network operator. Perhaps it is
good strengthen the idea that TCMTF is also beneficial for the development
of end-to-end aplications. 
Julián

Hi,

 

 

Do you like it?

 

Best regards,

Jose