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

From: FERNANDO PASCUAL BLANCO <[email-masked]>
Date: Tue, 15 Jan 2013 14:41:56 +0000

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

From: Mirko Sužnjević <[email-masked]<mailto:[email-masked]>>
Date: jueves, 13 de diciembre de 2012 10:06
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
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 ([email-masked]<mailto:[email-masked]>), 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

---

From: Mirko Sužnjević <[email-masked]>
Date: Tue, 15 Jan 2013 16:48:59 +0100

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:

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.

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!

Ok will be done.

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

Ok.

Thanks again for the feedback!

Cheers!
Mirko

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

Hi Mirko,

Hope to help!

Regards,

Fernando Pascual Blanco

TECHNOLOGY PEOPLE GROUP

F +34913128779

M +34682005168

[email-masked]

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

Hello,

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

Sincerely,

Mirko Suznjevic

---

From: FERNANDO PASCUAL BLANCO <[email-masked]>
Date: Thu, 17 Jan 2013 09:07:30 +0000

Hi Mirko,

Thank you for considering that. In addition, one more thing: in section 4, the sentence "If a policy defining a multiplexing period is used, then the average latency added to each packet will be half the multiplexing period." only applies when there is not enough packet rate to fulfill a big packet by multiplexing small ones. When  there is a lot of packets to multiplex, in general, multiplexing period will not be reached, so half the multiplexing period will be the maximum/worse average added delay. In general, and when TCMTF is working fine, average added delay will be lower.
So, I would rewrite that phrase as: "If a policy defining a multiplexing period is used, then the average latency added to each packet will be half the time to fulfill a multiplexed one. In the worse case and if the multiplexing period is reached, the average latency added to each packet will be half the multiplexing period".

What do you think?

Regards,

Fernando Pascual Blanco

From: Mirko Sužnjević <[email-masked]<mailto:[email-masked]>>
Date: martes, 15 de enero de 2013 16:48
To: Fernando Pascual Blanco <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [tcmtf] Draft: Maximum Tolerable Delays when using Tunneling Compressed Multiplexed Traffic Flows

Hello,

  *   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.

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

Hi Mirko,

Regards,

Fernando Pascual Blanco

Hello,

Sincerely,
Mirko Suznjevic

---

From: Mirko Sužnjević <[email-masked]>
Date: Fri, 18 Jan 2013 11:15:02 +0100

Yes I concur, it is a good notice. I am adding your comment to the review list for the next version.

Mirko Suznjevic

From: FERNANDO PASCUAL BLANCO [mailto:[email-masked]] 
Sent: Thursday, January 17, 2013 10:08 AM
To: Mirko Sužnjević; [email-masked]; [email-masked]
Subject: Re: [tcmtf] Draft: Maximum Tolerable Delays when using Tunneling Compressed Multiplexed Traffic Flows

Hi Mirko,

What do you think?

Regards,

Fernando Pascual Blanco

TECHNOLOGY PEOPLE GROUP

F +34913128779

M +34682005168

[email-masked]

From: Mirko Sužnjević <[email-masked]>
Date: martes, 15 de enero de 2013 16:48
To: Fernando Pascual Blanco <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [tcmtf] Draft: Maximum Tolerable Delays when using Tunneling Compressed Multiplexed Traffic Flows

Hello,

Ok will be done.

Ok.

Cheers!
Mirko

Hi Mirko,

Hope to help!

Regards,

Fernando Pascual Blanco

TECHNOLOGY PEOPLE GROUP

F +34913128779

M +34682005168

[email-masked]

Hello,

Sincerely,

Mirko Suznjevic

---

From: "Michael Ramalho (mramalho)" <[email-masked]>
Date: Fri, 18 Jan 2013 14:05:18 +0000

All,

Strictly speaking, the sentence ""If a policy defining a multiplexing period is used, then the average latency added to each packet will be half the multiplexing period."" makes an explicit assumption that the packet arrivals (for TCMTF packets) are random/uniform (or even that the arrival pdf is one sided, with the most of the pdf area/contribution below the mean delay).

Why even go there?

If someone has such a "policy" ... the policy is to define the maximum worst-case TCMTF (encoding) delay. If the TCMTF encoder has not yet built a "near-MTU" packet and the worst-case delay timer fires ... push the packet out!

The worst-case TCMTF delay we should introduce is determined by the packets we want to multiplex within a TCMTF packet. If we knew their traffic class ... we would have an idea of what the worst case should be. If we didn't, but rather made a reasonable assumption (for example, based on signature analysis), then we push when our idea of what the worst case has been met.

Given that the sentence referenced above is not correct (it has an implicit random arrival process assumption) - we need to clarify it if it is decided to keep it.

As Gorry notes in the next email on this thread, some delay-based congestion controls may respond to TCMTF-induced delay as an indication of increasing congestion in their congestion control. Anything we can do to limit the maximum delay (i.e., have a "nice" TCMTF-induced delay distribution) would be appreciated.

Michael Ramalho

From: [email-masked] [mailto:[email-masked]] On Behalf Of Mirko Sužnjevic
Sent: Friday, January 18, 2013 5:15 AM
To: FERNANDO PASCUAL BLANCO; [email-masked]; [email-masked]
Subject: Re: [tsvwg] [tcmtf] Draft: Maximum Tolerable Delays when using Tunneling Compressed Multiplexed Traffic Flows

Mirko Suznjevic

Hi Mirko,

What do you think?

Regards,

Fernando Pascual Blanco

Hello,

Hi Mirko,

Regards,

Fernando Pascual Blanco

Hello,

Sincerely,
Mirko Suznjevic