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

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

Michael,

 

In our research studies, we first thought about VoIP. In that case, if
everyone uses the same codec, you just have to wait in order to get a packet
from each flow. (This would not be true if silence suppression is applied,
however).

 

But other services, like games, do not have a fixed cadence. If you look at
this paper
(http://diec.unizar.es/~jsaldana/personal/commag_nov_2011_jsaldana.pdf) , in
which 8 games were analyzed, you may see that each one has a different
inter-packet time histogram.

 

We thought about different policies for defining which native packet goes in
which multiplexed packet:

 

- Fixed number of packets: Once you have N packets, you send the multiplexed
one

- Size limit: Once you reach a size (next to MTU), you send the multiplexed
one

- Period: You send a multiplexed packet every Period

- Timeout: (Very similar to "period") When a packet arrives, if a timeout
expires, you include it in the bundle and send it

 

Logically, "period" should be always combined with "size limit": if you have
an MTU packet, waiting more would be stupid. So the traffic class or the
signature analysis can give you the maximum period, but you should also use
the "size limit".

 

The question is that we are grouping a number of flows, which may be high.
In that case, the assumption of having a uniform distribution is not far
from reality. However, perhaps we could avoid 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."

 

The paragraph can begin with the next one: "A tradeoff appears: the longer
the multiplexing period, the higher the number of packets which can be
grouped, thus obtaining better bandwidth savings." 

 

What do you think?

 

Jose

 

De: [e-mail] [mailto:[e-mail]] En nombre de
Michael Ramalho (mramalho)
Enviado el: viernes, 18 de enero de 2013 15:05
Para: Mirko Sužnjević; FERNANDO PASCUAL BLANCO; [e-mail];
[e-mail]
Asunto: Re: [tsvwg] [tcmtf] Draft: Maximum Tolerable Delays when using
Tunneling Compressed Multiplexed Traffic Flows

 

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: [e-mail] [mailto:[e-mail]] On Behalf Of
Mirko Sužnjevic
Sent: Friday, January 18, 2013 5:15 AM
To: FERNANDO PASCUAL BLANCO; [e-mail]; [e-mail]
Subject: Re: [tsvwg] [tcmtf] Draft: Maximum Tolerable Delays when using
Tunneling Compressed Multiplexed Traffic Flows

 

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:[e-mail]] 
Sent: Thursday, January 17, 2013 10:08 AM
To: Mirko Sužnjević; [e-mail]; [e-mail]
Subject: Re: [tcmtf] Draft: Maximum Tolerable Delays when using Tunneling
Compressed Multiplexed Traffic Flows

 

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

Telefónica Global Resources

Network Automation and Dynamization

TECHNOLOGY PEOPLE GROUP

F [phone]

M [phone]

[e-mail]

 

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

 

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

 

  _____  


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