Re: [tcmtf] Draft: Maximum Tolerable Delays when using Tunneling Compressed Multiplexed Traffic Flows

[Mirko Sužnjević <[e-mail]>]

Hello,

Thanks for all the comments, I will briefly respond to them, and include your (as well as previous) corrections in a new version of the draft:

*	I do not understand the sentence "Therefore, we neither take into account services using an approach in which all the calculations are deployed in the server, which sends a real-time video stream to the client." in section 3.

The meaning of this sentence is that we will not be looking at the cloud based gaming services such as OnLive or Gaiki as they are focused on performing all needed calculations of the gamestate on the server, and sending a very "fat" video stream to the client which only renders the video. Therefore they are not suitable for tcmtf. I will change that in order to be more clear.

*	In section 3 (Considered Services), I think it could be also interesting to consider non-real time services candidates to be TCMTF optimized. For example services like instant messaging, where the bandwidth saving is the main benefit of the TCMTF optimization, should be somehow mentioned, establishing a kind of delay upper threshold. Related to that, in section 3, when talking about web browsing, the sentence "there is no need for policy limitations in TCMTF" could be disappointed, because actually there are limitations (ITU-T_G.1010, 10 seconds for web browsing, as in section 4.1 10 seconds are considered for streaming audio).

At first when we were discussing we decided that it will be focused on real-time services, but this can be broadened to others non-real-time. I think giving such upper limits has a point, although would we even employ tcmtf in cases  in which we will not have enough data to send a packet in 5 or more seconds? Is that feasible? Maybe in some sensor networks? Maybe I am just looking it the wrong way, maybe we would have a lot of traffic that needs to be packed ASAP!

*	In section 4, I would change the sentence "A number of flows are multiplexed together before being sent through the Internet." for "A number of flows are multiplexed together before being sent through the network.", because the network could not be necessary the Internet, I would also adapt Figure 2.

Ok will be done.

*	Maybe the creation of a section 4.4 talking about non real time services could be considered including last comments (acceptable with the recommendation appearing in the last sentence of the section 4.3 "It should be noted that multiplexing periods of about 1 second can be considered as enough for non real time services (e.g., web browsing and streaming audio).")

Ok, seems sound enough. I will write it and see which format looks better.

*	Table 1 could be included in a separate section (i.e. Section 4.5) as a summary

Ok.

 

Thanks again for the feedback!

Cheers!
Mirko

 

From: FERNANDO PASCUAL BLANCO [mailto:[e-mail]] 
Sent: Tuesday, January 15, 2013 3:42 PM
To: Mirko Sužnjević; [e-mail]; [e-mail]
Subject: Re: [tcmtf] Draft: Maximum Tolerable Delays when using Tunneling Compressed Multiplexed Traffic Flows

 

Hi Mirko,

 

Some comments to the draft:

*	In the introduction it says "TCTMF", it is "TCMTF".
*	I do not understand the sentence "Therefore, we neither take into account services using an approach in which all the calculations are deployed in the server, which sends a real-time video stream to the client." in section 3.
*	In section 3 (Considered Services), I think it could be also interesting to consider non-real time services candidates to be TCMTF optimized. For example services like instant messaging, where the bandwidth saving is the main benefit of the TCMTF optimization, should be somehow mentioned, establishing a kind of delay upper threshold. Related to that, in section 3, when talking about web browsing, the sentence "there is no need for policy limitations in TCMTF" could be disappointed, because actually there are limitations (ITU-T_G.1010, 10 seconds for web browsing, as in section 4.1 10 seconds are considered for streaming audio).
*	In section 4, I would change the sentence "A number of flows are multiplexed together before being sent through the Internet." for "A number of flows are multiplexed together before being sent through the network.", because the network could not be necessary the Internet, I would also adapt Figure 2.
*	Maybe the creation of a section 4.4 talking about non real time services could be considered including last comments (acceptable with the recommendation appearing in the last sentence of the section 4.3 "It should be noted that multiplexing periods of about 1 second can be considered as enough for non real time services (e.g., web browsing and streaming audio).")
*	Table 1 could be included in a separate section (i.e. Section 4.5) as a summary

Hope to help!

 

Regards,

 

Fernando Pascual Blanco

Telefónica Global Resources

Network Automation and Dynamization

TECHNOLOGY PEOPLE GROUP

F [phone]

M [phone]

[e-mail]

 

From: Mirko Sužnjević <[e-mail]>
Date: jueves, 13 de diciembre de 2012 10:06
To: "[e-mail]" <[e-mail]>rg>, "[e-mail]" <[e-mail]>
Subject: [tcmtf] Draft: Maximum Tolerable Delays when using Tunneling Compressed Multiplexed Traffic Flows

 

Hello,

 

We have just submitted the draft named Maximum Tolerable Delays when using Tunneling Compressed Multiplexed Traffic Flows: http://datatracker.ietf.org/doc/draft-suznjevic-tsvwg-mtd-tcmtf/

 

It is an extension of tcmtf http://datatracker.ietf.org/doc/draft-saldana-tsvwg-tcmtf/. Since a specific list for tcmtf exists ([e-mail]), the idea is to discuss it there.

 

The draft contains recommendations for TCMTF multiplexing period for different real-time services. In order to prevent QoE degradation of real-time services using TCMTF, a policy defining  a multiplexing period can be employed. Values of maximum tolerable delays presented in the draft form the base of such policy.    The recommendations are presented for real-time network services in which TCTMF bandwidth optimization is applicable (i.e., services  which have low payload to header size ratio which results in high protocol overhead).

 

Your feedback will be welcome. Thank you.


Sincerely,

Mirko Suznjevic

 

________________________________


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