Re: [tcmtf] TCMTF BOF description

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

Perhaps we could modify the second paragraph, including some bullets for the
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

- 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: [e-mail] [mailto:[e-mail]] En nombre de
Julián Fernández-Navajas
Enviado el: jueves, 06 de junio de 2013 10:08
Para: [e-mail]
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


El 05/06/2013 13:17, Jose Saldana escribió:

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 

 






_______________________________________________
tcmtf mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/tcmtf