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 17:03:34 +0000

Hi all,

        To re-open that issue, I would suggest that given that the delay is so
sensitive in real time services, we need to find a consensus here.

        My opinion is that to apply the first possibility (the static
multiplexing period) we need to suppose that the network conditions are
really bad, to be protected when the network congestion arises. In that
case, the application of the TCMTF optimization will not be optimal, so
that would be the less preferred option, but easier to implement and
maintain over the time.

        On the other hand, the second possibility would be the preferred. It is
easy to know the delay between the mux and the demux but most of the times
will not be enough unless mux and demux were really near from the client
and the server respectively. I agree with Jose in the possibility of snoop
RTCP packets in order to adapt the multiplexing period when multiplexing
RTP packets (and RTCP is available). Talking about RTT, I´m not sure if
RTT would be useful given that the multiplexing period only affect the one
way delay (OWD). Imagine the following scenario:
        - Client - Mux/Demux - Demux/Mux - Server (two ways TCMTF, TWTCMTF :P)
        - The OWD from server to client get increased
        - The OWD from client to server remains equal
        - Should we use a lower multiplexing period in the client to server
direction? I don´t think so… because we should use a lower multiplexing
period in the other direction.

        My point is that the multiplexing period should only be affected by the
OWD and not by the RTT (or it may be application dependent). How to
calculate the OWD? I´ve been reading something about OWAMP and it seems
that an specific software has to be implemented in the client/server side.
Can we assume that? Unfortunately I cannot contribute so much here…
        It is possible that for certain services the static (and worst case)
multiplexing period would be the better solution.

        What do you think?

Regards,

Fernando Pascual Blanco
Telefónica Global Resources
Network Automation and Dynamization
TECHNOLOGY PEOPLE GROUP
F +34913128779
M +34682005168
[email-masked]

On 17/12/12 12:25, "Jose Saldana" <[email-masked]> wrote:

>Hi all,
>
>Julian and I have been discussing about this. Some ideas have arisen. This
>is the summary.
>
>This would be the scheme of the system, including mux and demux:
>
>Real-time application ------- mux -------- internet --------- demux
>-------
>server
>
>
>I think perhaps the draft could say something like:
>
>When setting the multiplexing period, there are two possibilities:
>
>1.- Static / permanent: At system setup time, network delays are measured,
>and a multiplexing period is selected and set in the multiplexer.
>
>2.- Dynamic: A mechanism is used so as to adapt to the evolution of
>network
>delays. In this case, different mechanisms can be used in order to obtain
>periodical end-to-end network delay estimations, which would be useful in
>order to set the multiplexing period:
>
>- If the traffic is RTP, then RTCP packets containing the estimation could
>be analyzed in order to extract these values, as Dan suggests. The
>question
>is: would that packets travel through the multiplexer?
>- If the traffic is TCP, perhaps something similar to the RTT estimation
>of
>TCP could be useful.
>- If the traffic is UDP, should the mux use something like OWAMP
>(http://tools.ietf.org/html/rfc4656) in order to calculate two delays
>(application to mux, and mux to server) and calculate the sum?
>
>
>I think the draft is only supposed to report the maximum delays normally
>considered acceptable. Perhaps the additional mechanisms for calculating
>the
>RTT could just be suggested.
>
>What do you think?
>
>Jose
>
>> -----Mensaje original-----
>> De: [email-masked] [mailto:[email-masked]] En nombre de
>> Dan Wing
>> Enviado el: viernes, 14 de diciembre de 2012 18:33
>> Para: [email-masked]; 'Mirko Sužnjević'
>> CC: [email-masked]
>> Asunto: Re: [tcmtf] Draft: Maximum Tolerable Delays when using Tunneling
>> Compressed Multiplexed Traffic Flows
>>
>> > -----Original Message-----
>> > From: Jose Saldana [mailto:[email-masked]]
>> > Sent: Friday, December 14, 2012 2:58 AM
>> > To: 'Dan Wing'; 'Mirko Sužnjević'
>> > Cc: [email-masked]
>> > Subject: RE: [tcmtf] Draft: Maximum Tolerable Delays when using
>> > Tunneling Compressed Multiplexed Traffic Flows
>> >
>> > Dan,
>> >
>> > Regarding the use of the maximum delay, some days ago we discussed
>> > about
>> > it:
>> > the actual OWD of the network should be measured (or estimated) in
>> > order to know the maximum multiplexing period we can set.
>> >
>> > We may have this formula, if thinking one-way:
>> >
>> > OWD  + Mux period/2  < tolerable_OWD
>> >
>> > If we think RTT:
>> >
>> > OWD + Mux period/2 + OWD back < 2*tolerable_OWD
>> >
>> > I don't know if we should include a mechanism for estimating OWD in
>> > tcmtf. I think this is more an implementation problem, which may be
>> > already solved.
>>
>> Yes, it's already solved end-to-end:  RTP with RTCP feedback allows
>> determining one way delay.
>>
>> But if something in the middle is multiplexing several packets together,
>we
>> don't want it to add too much delay.  That thing in the middle won't
>> necessarily know the one way delay seen by the endpoints, unless it
>> analyzes the RTP and RTCP.  There are devices that do that on the
>>market,
>> mostly to diagnose where networks are causing loss/delay with RTP flows.
>>
>>
>> > Another option is using some typical values, e.g. from
>> > http://ipnetwork.bgtmo.ip.att.net/pws/global_network_avgs.html
>> >
>> > The draft includes some preliminary/recommended values for the
>> > Multiplexing Period. Is this interesting? Should we put the formula
>> > instead?
>>
>> It's probably sufficient as-is.
>>
>> -d
>>
>> > Mirko, another question: in online games, players usually talk about
>> > the "ping", and I think it means RTT. Don't you think it would be
>> > better to define a RTT limit instead of a OWD one in that case?
>> >
>> > What do you think?
>> >
>> > Jose
>> >
>> > > -----Mensaje original-----
>> > > De: [email-masked] [mailto:[email-masked]] En nombre
>> > > de Dan Wing Enviado el: jueves, 13 de diciembre de 2012 17:07
>> > > Para: 'Mirko Sužnjević'; [email-masked]
>> > > Asunto: Re: [tcmtf] Draft: Maximum Tolerable Delays when using
>> > > Tunneling Compressed Multiplexed Traffic Flows
>> > >
>> > > > -----Original Message-----
>> > > > From: [email-masked] [mailto:[email-masked]] On
>> > > > Behalf Of Mirko Sužnjevic
>> > > > Sent: Thursday, December 13, 2012 1:07 AM
>> > > > To: [email-masked]; [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/
>> > >
>> > > The suggested 400ms for interactive voice is at least 2x too high.
>> > > I
>> > expect
>> > > that number does not include the playout jitter buffer (which is
>> > > variable,
>> > but
>> > > usually a few samples, so 40-80ms).  200ms end-to-end is the higher
>> > > end,
>> > and
>> > > that includes jitter buffer, codec processing, and so on.
>> > >
>> > > But, more importantly:  it seems valuable for endpoints to signal
>> > > their maximum delay somehow.  Or would the TCMTF function
>> determine
>> > > the maximum delay, using some heuristic?
>> > >
>> > > How does the TCMTF function determine how much of that 'tolerable
>> > > latency' budget it can consume?
>> > >
>> > > -d
>> > >
>> > >
>> > > > 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.
>> > > >
>> > > >
>> > > >
>> > > > 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
>> > >
>> > >
>> > > _______________________________________________
>> > > tcmtf mailing list
>> > > [email-masked]
>> > > https://www.ietf.org/mailman/listinfo/tcmtf
>>
>> _______________________________________________
>> tcmtf mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/tcmtf
>
>_______________________________________________
>tcmtf mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/tcmtf

________________________________

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: "Jose Saldana" <[email-masked]>
Date: Wed, 16 Jan 2013 11:57:16 +0100

My two cents:

In games and in VoIP the really important thing is RTT:

- Games always measure the RTT (gamers talk about the "ping"): the important thing is the delay from a player action to the server reaction arriving to the player's machine.
- In VoIP I think it is the same: what matters is the RTT, in order to grant interactivity and avoiding cross-talk.

In addition, RTT is easier to measure than OWD, since you don't need synchronization.

And regarding Two-way TCMTF, I think we have to think about TCMTF as one-way. Otherwise, things would become very complicated. Some services have very different client-server and server-client traffic patterns (e.g. games). In addition, sometimes the two flows can follow different network paths. I think once we talked about a network provider using a number of ISPs.

However, using RTT for tuning a one-way TCMTF may not be bad... or is it bad? Any other thoughts?

BR,

Jose

> De: FERNANDO PASCUAL BLANCO [mailto:[email-masked]]
> Enviado el: martes, 15 de enero de 2013 18:04
> Para: [email-masked]; 'Dan Wing'; 'Mirko Sužnjević'; Julián Fernández
> Navajas
> CC: [email-masked]
>         My opinion is that to apply the first possibility (the static multiplexing
> period) we need to suppose that the network conditions are really bad, to be
> protected when the network congestion arises. In that case, the application
> of the TCMTF optimization will not be optimal, so that would be the less
> preferred option, but easier to implement and maintain over the time.
> 
> easy to know the delay between the mux and the demux but most of the
> times will not be enough unless mux and demux were really near from the
> client and the server respectively. I agree with Jose in the possibility of snoop
> RTP packets (and RTCP is available). Talking about RTT, I´m not sure if RTT
> would be useful given that the multiplexing period only affect the one way
> delay (OWD). Imagine the following scenario:
> calculate the OWD? I´ve been reading something about OWAMP and it
> seems that an specific software has to be implemented in the client/server
> side.
> >Julian and I have been discussing about this. Some ideas have arisen.
> >This is the summary.
> >
> >1.- Static / permanent: At system setup time, network delays are
> >measured, and a multiplexing period is selected and set in the multiplexer.
> >
> >network delays. In this case, different mechanisms can be used in order
> >to obtain periodical end-to-end network delay estimations, which would
> >be useful in order to set the multiplexing period:
> >
> >- If the traffic is RTP, then RTCP packets containing the estimation
> >could be analyzed in order to extract these values, as Dan suggests.
> >The question
> >- If the traffic is TCP, perhaps something similar to the RTT
> >estimation of TCP could be useful.
> >I think the draft is only supposed to report the maximum delays
> >normally considered acceptable. Perhaps the additional mechanisms for
> >calculating the RTT could just be suggested.
> >
> >What do you think?
> >
> >Jose
> >
> >> de Dan Wing Enviado el: viernes, 14 de diciembre de 2012 18:33
> >>market,  mostly to diagnose where networks are causing loss/delay with
> >>RTP flows.
> >>
> >>
> >> > Mirko, another question: in online games, players usually talk
> >> > about the "ping", and I think it means RTT. Don't you think it
> >> > would be better to define a RTT limit instead of a OWD one in that case?
> >> >
> >> > What do you think?
> >> >
> >> > Jose
> >> >
> >> > > De: [email-masked] [mailto:[email-masked]] En
> >> > > nombre de Dan Wing Enviado el: jueves, 13 de diciembre de 2012
> >> > > 17:07
> >> > > usually a few samples, so 40-80ms).  200ms end-to-end is the
> >> > > higher end,
> >> > and
> >> > > > 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
> >> > > > optimization is applicable (i.e., services  which have low
> >> > > > payload to header size ratio which results in high protocol
> overhead).
> >> > > >
> >> > > >
> >> > > >
> 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:

---

From: FERNANDO PASCUAL BLANCO <[email-masked]>
Date: Wed, 16 Jan 2013 11:51:53 +0000

Hi Jose,

        You are right, but my point here is:

                Client - Mux - Demux - Server

        Imagine that there is enough packets between mux and demux to make the
added delay very small (TCMTF is working very well and the mux has not to
wait the multiplexing period to fulfill a big packet and send it, so
imagine a multiplexing period of 50 ms and a big packet is fulfilled in 5
ms). If the RTT get increased because a congestion in the way back to the
client (there is no TCMTF optimization) and we decrease the multiplexing
period (even in the extreme we can disable the TCMTF optimization) the
high RTT will remain. Even if the TCMTF optimization was helping in the
client to server path, disabling it may harm. Do you think that scenario
would be possible?

        So I´m not sure about that, I think we need more opinions here.

Regards,

Fernando Pascual Blanco

On 16/01/13 11:57, "Jose Saldana" <[email-masked]> wrote:

>- Games always measure the RTT (gamers talk about the "ping"): the
>important thing is the delay from a player action to the server reaction
>arriving to the player's machine.
>- In VoIP I think it is the same: what matters is the RTT, in order to
>grant interactivity and avoiding cross-talk.
>
>And regarding Two-way TCMTF, I think we have to think about TCMTF as
>one-way. Otherwise, things would become very complicated. Some services
>have very different client-server and server-client traffic patterns
>(e.g. games). In addition, sometimes the two flows can follow different
>network paths. I think once we talked about a network provider using a
>number of ISPs.
>
>>multiplexing
>>RTT

---

From: "Jose Saldana" <[email-masked]>
Date: Thu, 17 Jan 2013 13:16:51 +0100

Fernando,

So you may have this case:
- your multiplexing delay limit is 50 ms
- you have a lot of flows to multiplex, so perhaps the time between multiplexed packets will be 5 ms
- you detect an increase in RTT
- the system reacts and reduces multiplexing period
- in fact, the reduction doesn't matter until the period is reduced to less than 5 ms

So you only have to make this decision: using tcmtf with 5 ms period or not. If RTT is critical you may not be interested on saving bandwidth, but on reducing a bit the RTT.

So I think your question is: what happens if the RTT is very big (out of limits) and you can save bandwidth using a 5ms multiplexing period?

For example, the maximum RTT for a good quality is 80 ms and your network has 120 just now. In this case, perhaps having 125 doesn't matter, if you can save bandwidth.

This makes sense, but it is a "extreme" case. However, would it be any advantage if OWD is used instead of RTT?

Best regards,

Jose

> Enviado el: miércoles, 16 de enero de 2013 12:52
> Para: [email-masked]; 'Dan Wing'; 'Mirko Sužnjević'; 'Julián Fernández
> Navajas'
> CC: [email-masked]
>         Imagine that there is enough packets between mux and demux to make
> the added delay very small (TCMTF is working very well and the mux has not
> to wait the multiplexing period to fulfill a big packet and send it, so imagine a
> multiplexing period of 50 ms and a big packet is fulfilled in 5 ms). If the RTT
> get increased because a congestion in the way back to the client (there is no
> TCMTF optimization) and we decrease the multiplexing period (even in the
> extreme we can disable the TCMTF optimization) the high RTT will remain.
> Even if the TCMTF optimization was helping in the client to server path,
> disabling it may harm. Do you think that scenario would be possible?
> 
> >important thing is the delay from a player action to the server
> >reaction arriving to the player's machine.
> >> De: FERNANDO PASCUAL BLANCO [mailto:[email-masked]]  Enviado el:
> martes,
> >>15 de enero de 2013 18:04
> >> Para: [email-masked]; 'Dan Wing'; 'Mirko Sužnjević'; Julián
> >>Fernández  Navajas
> >> CC: [email-masked]
> >>         To re-open that issue, I would suggest that given that the
> >>delay is so  sensitive in real time services, we need to find a
> >>consensus here.
> >>
> >> period) we need to suppose that the network conditions are really
> >>bad, to be  protected when the network congestion arises. In that
> >>case, the application  of the TCMTF optimization will not be optimal,
> >>so that would be the less  preferred option, but easier to implement
> >>and maintain over the time.
> >>
> >>         On the other hand, the second possibility would be the
> >>preferred. It is  easy to know the delay between the mux and the demux
> >>but most of the  times will not be enough unless mux and demux were
> >>really near from the  client and the server respectively. I agree with
> >>Jose in the possibility of snoop  RTCP packets in order to adapt the
> >>multiplexing period when multiplexing  RTP packets (and RTCP is
> >>available). Talking about RTT, I´m not sure if RTT  would be useful
> >>given that the multiplexing period only affect the one way  delay
> >>(OWD). Imagine the following scenario:
> >>         - Should we use a lower multiplexing period in the client to
> >>server  direction? I don´t think so… because we should use a lower
> >>multiplexing  period in the other direction.
> >>
> >>         My point is that the multiplexing period should only be
> >>affected by the  OWD and not by the RTT (or it may be application
> >>dependent). How to  calculate the OWD? I´ve been reading something
> >>about OWAMP and it  seems that an specific software has to be
> >>implemented in the client/server  side.
> >>         It is possible that for certain services the static (and
> >>worst
> >>case)
> >> >network delays. In this case, different mechanisms can be used in
> >> >order to obtain periodical end-to-end network delay estimations,
> >> >which would be useful in order to set the multiplexing period:
> >> >
> >> >(http://tools.ietf.org/html/rfc4656) in order to calculate two
> >> >delays (application to mux, and mux to server) and calculate the sum?
> >> >
> >> >
> >> >normally considered acceptable. Perhaps the additional mechanisms
> >> >for calculating the RTT could just be suggested.
> >> >
> >> >What do you think?
> >> >
> >> >Jose
> >> >
> >> >> nombre de Dan Wing Enviado el: viernes, 14 de diciembre de 2012
> >> >> 18:33
> >> >> > Regarding the use of the maximum delay, some days ago we
> >> >> > discussed about
> >> >> > it:
> >> >> > the actual OWD of the network should be measured (or estimated)
> >> >> > in order to know the maximum multiplexing period we can set.
> >> >> >
> >> >> > I don't know if we should include a mechanism for estimating OWD
> >> >> > in tcmtf. I think this is more an implementation problem, which
> >> >> > may be already solved.
> >> >>
> >> >> Yes, it's already solved end-to-end:  RTP with RTCP feedback
> >> >> allows determining one way delay.
> >> >>
> >> >> don't want it to add too much delay.  That thing in the middle
> >> >>won't necessarily know the one way delay seen by the endpoints,
> >> >>unless it analyzes the RTP and RTCP.  There are devices that do
> >> >>that on the market,  mostly to diagnose where networks are causing
> >> >>loss/delay with RTP flows.
> >> >>
> >> >>
> >> >> > Multiplexing Period. Is this interesting? Should we put the
> >> >> > formula instead?
> >> >>
> >> >> > would be better to define a RTT limit instead of a OWD one in
> >> >> > that
> >>case?
> >> >> >
> >> >> > What do you think?
> >> >> >
> >> >> > Jose
> >> >> >
> >> >> > > > From: [email-masked] [mailto:[email-masked]]
> >> >> > > > On Behalf Of Mirko Sužnjevic
> >> >> > > > 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-tc
> >> >> > > > mtf
> >> >> > > > /
> >> >> > >
> >> >> > > that number does not include the playout jitter buffer (which
> >> >> > > is variable,
> >> >> > but
> >> >> > > But, more importantly:  it seems valuable for endpoints to
> >> >> > > signal their maximum delay somehow.  Or would the TCMTF
> >> >> > > function
> >> >> determine
> >> >> > > How does the TCMTF function determine how much of that
> >> >> > > 'tolerable latency' budget it can consume?
> >> >> > >
> >> >> > > -d
> >> >> > >
> >> >> > >
> >> 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:

---

From: FERNANDO PASCUAL BLANCO <[email-masked]>
Date: Thu, 17 Jan 2013 13:38:53 +0000

Jose,

        Let´s say that playing with the OWD you have more granularity in order to
know in which direction you need to reduce the delay by reducing the
multiplexing delay. But people with more knowledge about online games will
provide us more information for sure.

Regards,

Fernando Pascual Blanco

On 17/01/13 13:16, "Jose Saldana" <[email-masked]> wrote:

>So you only have to make this decision: using tcmtf with 5 ms period or
>not. If RTT is critical you may not be interested on saving bandwidth,
>but on reducing a bit the RTT.
>
>So I think your question is: what happens if the RTT is very big (out of
>limits) and you can save bandwidth using a 5ms multiplexing period?
>
>For example, the maximum RTT for a good quality is 80 ms and your network
>has 120 just now. In this case, perhaps having 125 doesn't matter, if you
>can save bandwidth.
>

---

From: "Jose Saldana" <[email-masked]>
Date: Thu, 17 Jan 2013 14:50:55 +0100

In addition, perhaps we are too focused on online games and VoIP services. There are other services which are one-way: perhaps M2M communications do not require a two way communication. We can think about a number of sensors sending their measurements to a central server. So perhaps RTT will not even exist in this case.

Jose

> Enviado el: jueves, 17 de enero de 2013 14:39
> >For example, the maximum RTT for a good quality is 80 ms and your
> >network has 120 just now. In this case, perhaps having 125 doesn't
> >matter, if you can save bandwidth.
> >
> >>miércoles, 16 de enero de 2013 12:52
> >> Para: [email-masked]; 'Dan Wing'; 'Mirko Sužnjević'; 'Julián
> >>Fernández  Navajas'
> >> CC: [email-masked]
> >>         Imagine that there is enough packets between mux and demux to
> >>make  the added delay very small (TCMTF is working very well and the
> >>mux has not  to wait the multiplexing period to fulfill a big packet
> >>and send it, so imagine a  multiplexing period of 50 ms and a big
> >>packet is fulfilled in 5 ms). If the RTT  get increased because a
> >>congestion in the way back to the client (there is no  TCMTF
> >>optimization) and we decrease the multiplexing period (even in the
> >> Even if the TCMTF optimization was helping in the client to server
> >>path,  disabling it may harm. Do you think that scenario would be possible?
> >>
> >> >- In VoIP I think it is the same: what matters is the RTT, in order
> >> >to grant interactivity and avoiding cross-talk.
> >> >
> >> >(e.g. games). In addition, sometimes the two flows can follow
> >> >different network paths. I think once we talked about a network
> >> >provider using a number of ISPs.
> >> >
> >> >>case, the application  of the TCMTF optimization will not be
> >> >>optimal, so that would be the less  preferred option, but easier to
> >> >>implement and maintain over the time.
> >> >>
> >> >>preferred. It is  easy to know the delay between the mux and the
> >> >>demux but most of the  times will not be enough unless mux and
> >> >>demux were really near from the  client and the server
> >> >>respectively. I agree with Jose in the possibility of snoop  RTCP
> >> >>packets in order to adapt the multiplexing period when multiplexing
> >> >>RTP packets (and RTCP is available). Talking about RTT, I´m not
> >> >>sure if RTT  would be useful given that the multiplexing period
> >> >>only affect the one way  delay (OWD). Imagine the following scenario:
> >> >>         - Should we use a lower multiplexing period in the client
> >> >>to server  direction? I don´t think so… because we should use a
> >> >>lower multiplexing  period in the other direction.
> >> >>
> >> >> Network Automation and Dynamization TECHNOLOGY PEOPLE GROUP
> F
> >> >> +34913128779 M +34682005168 [email-masked]
> >> >>
> >> >>
> >> >>
> >> >>
> >> >> >2.- Dynamic: A mechanism is used so as to adapt to the evolution
> >> >> >of network delays. In this case, different mechanisms can be used
> >> >> >in order to obtain periodical end-to-end network delay
> >> >> >estimations, which would be useful in order to set the multiplexing
> period:
> >> >> >
> >> >> >- If the traffic is RTP, then RTCP packets containing the
> >> >> >estimation could be analyzed in order to extract these values, as Dan
> suggests.
> >> >> >The question
> >> >> >> > Subject: RE: [tcmtf] Draft: Maximum Tolerable Delays when
> >> >> >> > using Tunneling Compressed Multiplexed Traffic Flows
> >> >> >> >
> >> >> >> > Dan,
> >> >> >> >
> >> >> >> > the actual OWD of the network should be measured (or
> >> >> >> > estimated) in order to know the maximum multiplexing period we
> can set.
> >> >> >> >
> >> >> >> > I don't know if we should include a mechanism for estimating
> >> >> >> > OWD in tcmtf. I think this is more an implementation problem,
> >> >> >> > which may be already solved.
> >> >> >>
> >> >> >>that on the market,  mostly to diagnose where networks are
> >> >> >>causing loss/delay with RTP flows.
> >> >> >>
> >> >> >>
> >> >> >> > The draft includes some preliminary/recommended values for
> >> >> >> > the Multiplexing Period. Is this interesting? Should we put
> >> >> >> > the formula instead?
> >> >> >>
> >> >> >> > Mirko, another question: in online games, players usually
> >> >> >> > talk about the "ping", and I think it means RTT. Don't you
> >> >> >> > think it would be better to define a RTT limit instead of a
> >> >> >> > OWD one in that
> >> >>case?
> >> >> >> >
> >> >> >> > What do you think?
> >> >> >> >
> >> >> >> > Jose
> >> >> >> >
> >> >> >> > > De: [email-masked] [mailto:[email-masked]]
> >> >> >> > > En nombre de Dan Wing Enviado el: jueves, 13 de diciembre
> >> >> >> > > de 2012
> >> >> >> > > 17:07
> >> >> >> > > Asunto: Re: [tcmtf] Draft: Maximum Tolerable Delays when
> >> >> >> > > using Tunneling Compressed Multiplexed Traffic Flows
> >> >> >> > >
> >> >> >> > > > From: [email-masked]
> >> >> >> > > > [mailto:[email-masked]] On Behalf Of Mirko
> >> >> >> > > > Sužnjevic
> >> >> >> > > > Subject: [tcmtf] Draft: Maximum Tolerable Delays when
> >> >> >> > > > using Tunneling Compressed Multiplexed Traffic Flows
> >> >> >> > > >
> >> >> >> > > > Hello,
> >> >> >> > > >
> >> >> >> > > >
> >> >> >> > > >
> >> >> >> > > The suggested 400ms for interactive voice is at least 2x
> >> >> >> > > too
> >> >>high.
> >> >> >> > > I
> >> >> >> > expect
> >> >> >> > > that number does not include the playout jitter buffer
> >> >> >> > > (which is variable,
> >> >> >> > but
> >> >> >> > > usually a few samples, so 40-80ms).  200ms end-to-end is
> >> >> >> > > the higher end,
> >> >> >> > and
> >> >> >> > > > saldana-tsvwg-tcmtf/. Since a specific list for tcmtf
> >> >> >> > > > exists ([email-masked]), the idea is to discuss it there.
> >> >> >> > > >
> >> >> >> > > >
> >> >> >> > > >
> >> >> >> > > > 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
> >> >> >> > > > optimization is applicable (i.e., services  which have
> >> >> >> > > > low payload to header size ratio which results in high
> >> >> >> > > > protocol
> >> >> overhead).
> >> >> >> > > >
> >> >> >> > > >
> >> >> >> > > >
> >> >> 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:

---

From: Gorry Fairhurst <[email-masked]>
Date: Fri, 18 Jan 2013 10:25:28 +0000

If this is going to be used in the general Internet, then we need to 
decide whether there is one-way or two-way control connectivity. This 
will determine the constraints from a congestion control perspective. 
RTT and/or control feedback would be really helpful in establishing a 
congestion control or circuit-breaker function to ensure the traffic 
does not cause congestion collapse. Have you thought about this?

Gorry

---

From: "Jose Saldana" <[email-masked]>
Date: Mon, 21 Jan 2013 14:33:02 +0100

Gorry,

Regarding your question:
> congestion control or circuit-breaker function to ensure the traffic does not
> cause congestion collapse. Have you thought about this?

If I understand well, you are talking about using RTT or feedback not only for selecting an adequate multiplexing period, but also for congestion control. Is this true?

The question is that TCMTF is designed for traffic saving, so I think the cause of the congestion would not be TCMTF itself, but a high amount of flows, or a high bandwidth to aggregate. So perhaps in that case the flows which are being multiplexed will have their own end-to-end congestion control mechanisms.

An example: you are grouping a lot of TCP flows of an MMORPG game. If a bottleneck appears and delays rise, TCP mechanisms will act and reduce the rate.

Can we find an example in which interrupting the use of TCMTF and sending native packets instead will be necessary? Perhaps this one: if you are using TCMTF for reducing pps and not bandwidth. This can happen with VoIP in a satellite network: you group packets without header compression. You reduce pps and you increase bandwidth. However, I think bandwidth increase is really small: 25 bytes for the tunnel header and two more bytes for separating each multiplexed packet. If you are grouping 10 VoIP packets (20 IP/8 UDP/12 RTP/20 payload), the tunnel needs 25 + 10x(2+60)=645bytes. Native traffic would need 10x60=600 bytes. So bandwidth increase is 7.5%. If you group 20 packets, bandwidth increase is 1265/1200= 5%

Gorry, was this your idea? Are you thinking about other scenarios in which interrupting TCMTF can be interesting?

Thanks a lot,

Jose

> Gorry Fairhurst
> Enviado el: viernes, 18 de enero de 2013 11:25
> Para: [email-masked]
> If this is going to be used in the general Internet, then we need to decide
> whether there is one-way or two-way control connectivity. This will
> determine the constraints from a congestion control perspective.
> congestion control or circuit-breaker function to ensure the traffic does not
> cause congestion collapse. Have you thought about this?
> 
> Gorry
> 
> 
> 
> > In addition, perhaps we are too focused on online games and VoIP
> services. There are other services which are one-way: perhaps M2M
> communications do not require a two way communication. We can think
> about a number of sensors sending their measurements to a central server.
> So perhaps RTT will not even exist in this case.
> >
> > Jose
> >
> >> De: FERNANDO PASCUAL BLANCO [mailto:[email-masked]] Enviado el: jueves,
> >> 17 de enero de 2013 14:39
> >>          Let´s say that playing with the OWD you have more
> >> granularity in order to know in which direction you need to reduce
> >> the delay by reducing the multiplexing delay. But people with more
> >> knowledge about online games will provide us more information for sure.
> >>
> >> Regards,
> >>
> >> Fernando Pascual Blanco
> >>> So you only have to make this decision: using tcmtf with 5 ms period
> >>> or not. If RTT is critical you may not be interested on saving
> >>> bandwidth, but on reducing a bit the RTT.
> >>>
> >>> This makes sense, but it is a "extreme" case. However, would it be
> >>> any advantage if OWD is used instead of RTT?
> >>>
> >>> Best regards,
> >>>
> >>> Jose
> >>>
> >>>>          Imagine that there is enough packets between mux and demux
> >>>> to make  the added delay very small (TCMTF is working very well and
> >>>> the mux has not  to wait the multiplexing period to fulfill a big
> >>>> packet and send it, so imagine a  multiplexing period of 50 ms and
> >>>> a big packet is fulfilled in 5 ms). If the RTT  get increased
> >>>> because a congestion in the way back to the client (there is no
> >>>> TCMTF
> >>>>> - In VoIP I think it is the same: what matters is the RTT, in
> >>>>> order to grant interactivity and avoiding cross-talk.
> >>>>>
> >>>>> And regarding Two-way TCMTF, I think we have to think about TCMTF
> >>>>> as one-way. Otherwise, things would become very complicated.
> Some
> >>>> services
> >>>>> have very different client-server and server-client traffic
> >>>>> patterns (e.g. games). In addition, sometimes the two flows can
> >>>>> follow different network paths. I think once we talked about a
> >>>>> network provider using a number of ISPs.
> >>>>>
> >>>>>>          To re-open that issue, I would suggest that given that
> >>>>>> the delay is so  sensitive in real time services, we need to find
> >>>>>> a consensus here.
> >>>>>>
> >>>>>> optimal, so that would be the less  preferred option, but easier
> >>>>>> to implement and maintain over the time.
> >>>>>>
> >>>>>> packets in order to adapt the multiplexing period when
> >>>>>> multiplexing RTP packets (and RTCP is available). Talking about
> >>>>>> RTT, I´m not sure if RTT  would be useful given that the
> >>>>>> multiplexing period only affect the one way  delay (OWD). Imagine
> the following scenario:
> >>>>>>          - Should we use a lower multiplexing period in the
> >>>>>> client to server  direction? I don´t think so… because we should
> >>>>>> use a lower multiplexing  period in the other direction.
> >>>>>>
> >>>>>> dependent). How to  calculate the OWD? I´ve been reading
> >>>>>> something about OWAMP and it  seems that an specific software has
> >>>>>> to be implemented in the client/server  side.
> >>>>>>> of network delays. In this case, different mechanisms can be
> >>>>>>> used in order to obtain periodical end-to-end network delay
> >>>>>>> normally considered acceptable. Perhaps the additional
> >>>>>>> mechanisms for calculating the RTT could just be suggested.
> >>>>>>>
> >>>>>>> What do you think?
> >>>>>>>
> >>>>>>> Jose
> >>>>>>>
> En

---

From: FERNANDO PASCUAL BLANCO <[email-masked]>
Date: Mon, 21 Jan 2013 14:09:17 +0000

Hi all,

        I also think that the flows (TCP in that case) will have their own e2e
congestion control, and TCMTF will be something in the middle not aware
about that methods. In case of congestion (too much traffic at the mux),
by performing the TCMTF the situation could be solved, if not, packet
delay will be higher and the flow transmitter will generate packets slower.
        The problem is that the delay introduced by the TCMTF function could
trick the origin of the flow, thinking that the flow path is congested and
reducing the transmission rate. This is something that will have to be
addressed.

Regards,

Fernando Pascual Blanco

On 21/01/13 14:33, "Jose Saldana" <[email-masked]> wrote:

>>does not
>If I understand well, you are talking about using RTT or feedback not
>only for selecting an adequate multiplexing period, but also for
>congestion control. Is this true?
>
>The question is that TCMTF is designed for traffic saving, so I think the
>cause of the congestion would not be TCMTF itself, but a high amount of
>flows, or a high bandwidth to aggregate. So perhaps in that case the
>flows which are being multiplexed will have their own end-to-end
>congestion control mechanisms.
>
>An example: you are grouping a lot of TCP flows of an MMORPG game. If a
>bottleneck appears and delays rise, TCP mechanisms will act and reduce
>the rate.
>
>Can we find an example in which interrupting the use of TCMTF and sending
>native packets instead will be necessary? Perhaps this one: if you are
>using TCMTF for reducing pps and not bandwidth. This can happen with VoIP
>in a satellite network: you group packets without header compression. You
>reduce pps and you increase bandwidth. However, I think bandwidth
>increase is really small: 25 bytes for the tunnel header and two more
>bytes for separating each multiplexed packet. If you are grouping 10 VoIP
>packets (20 IP/8 UDP/12 RTP/20 payload), the tunnel needs 25 +
>10x(2+60)=645bytes. Native traffic would need 10x60=600 bytes. So
>bandwidth increase is 7.5%. If you group 20 packets, bandwidth increase
>is 1265/1200= 5%
>
>Gorry, was this your idea? Are you thinking about other scenarios in
>which interrupting TCMTF can be interesting?
>
>Thanks a lot,
>
>Jose
>
>>decide
>>does not

---

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 21 Jan 2013 14:40:07 +0000

Jose, see below.

Gorry

> If I understand well, you are talking about using RTT or feedback not only for selecting an adequate multiplexing period, but also for congestion control. Is this true?
My query was whether the MUX should implement some rate limit on the 
aggregate multiplexed flow - given this can then result in a higher rate 
flow with different characteristics to the original low-rate flows.

> The question is that TCMTF is designed for traffic saving, so I think the cause of the congestion would not be TCMTF itself, but a high amount of flows, or a high bandwidth to aggregate. So perhaps…
OK, if all the flows had CC, this would be less of an issue. If each 
flow is individually small without CC (or unlimited by CC, e.g. because 
it sends fewer than one packet per RTT), then aggregating these could 
make a large flow that has little CC. That seems more of an in issue 
than having lots of small flows. The aggregate flow would likely be more 
bursty for instance.

> An example: you are grouping a lot of TCP flows of an MMORPG game. If a bottleneck appears and delays rise, TCP mechanisms will act and reduce the rate.
Yes. Especially if the flow has appreciable packets/rtt.

> Can we find an example in which interrupting the use of TCMTF and sending native packets instead will be necessary?
 > Perhaps this one: if you are using TCMTF for reducing pps and not 
bandwidth.
> This can happen with VoIP in a satellite network: you group packets without header compression.
 > You reduce pps and you increase bandwidth.
 >
I would suggest this is a subnetwork problem, not general Internet 
problem - it seems like a form of link encapauslation/HC optimisation.

> However, I think bandwidth increase is really small: 25 bytes for the tunnel header and two more bytes for separating each multiplexed packet.
 > If you are grouping 10 VoIP packets (20 IP/8 UDP/12 RTP/20 payload), 
the tunnel needs 25 + 10x(2+60)=645bytes.
 > > Native traffic would need 10x60=600 bytes. So bandwidth increase is 
7.5%. If you group 20 packets, bandwidth increase is 1265/1200= 5%
I think the extra byte overhead is not significant. Tunnel encpas in the 
CORE is common, using GRE, etc and adds more overhead.

> Gorry, was this your idea? Are you thinking about other scenarios in which interrupting TCMTF can be interesting?
I'm interested to judging if there are cases where aggregating small 
flows (with minimal or no CC - as in VoIP) can result in an aggregate 
tunnel that competes unfairly with established flows that use CC.

---

From: "Michael Ramalho (mramalho)" <[email-masked]>
Date: Tue, 22 Jan 2013 15:41:30 +0000

All,

Although it is hard to parse who-said-what in the thread below ... I think Gorry asked the question:

" I'm interested to judging if there are cases where aggregating small 
flows (with minimal or no CC - as in VoIP) can result in an aggregate 
tunnel that competes unfairly with established flows that use CC."

To make the answer simple, consider the case where there are only two types of flows - TCP (representing all CC flows here) and VoIP (representing CBR or no-CC flows).

Now consider a bottleneck link filled with AGGREGATES of both types of flows. Define Sum_CC as the sum of the aggregated TCP flows and SUM_VoIP as the sum of the aggregated no-CC flows.

So long the bottleneck link has BW (BW_Total) greater than SUM_VoIP ... the individual TCP flows will divide what is left over. Note that the individual VoIP flows are "unfair", they don't care about their share of the bottleneck BW.

Ideally each TCP flow would get [BW_Total-SUM_VoIP]/N, when there are N TCP flows ... but it gets dicey when the remaining BW is small relative to BW_Total (many are starved).

So ... so long as SUM_VoIP is less than the sum of the individual VoIP flows (we had compression) ... we have not made the situation worse for the remaining TCP flows ... EXCEPT that we have added some delay to the TCP flows.

And this only hurts the TCP flows to the extent that they were cwnd limited (i.e., had enough data to send so that their individual CC were limiting the individual rates ... this is NOT the usual case for gaming).

I hope this helps.

Michael Ramalho

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Gorry Fairhurst
Sent: Monday, January 21, 2013 9:40 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [tcmtf] Draft: Maximum Tolerable Delays when using Tunneling Compressed Multiplexed Traffic Flows

Jose, see below.

Gorry

> If I understand well, you are talking about using RTT or feedback not only for selecting an adequate multiplexing period, but also for congestion control. Is this true?
My query was whether the MUX should implement some rate limit on the aggregate multiplexed flow - given this can then result in a higher rate flow with different characteristics to the original low-rate flows.

> The question is that TCMTF is designed for traffic saving, so I think the cause of the congestion would not be TCMTF itself, but a high amount of flows, or a high bandwidth to aggregate. So perhaps…
OK, if all the flows had CC, this would be less of an issue. If each flow is individually small without CC (or unlimited by CC, e.g. because it sends fewer than one packet per RTT), then aggregating these could make a large flow that has little CC. That seems more of an in issue than having lots of small flows. The aggregate flow would likely be more bursty for instance.

 > Perhaps this one: if you are using TCMTF for reducing pps and not bandwidth.
I would suggest this is a subnetwork problem, not general Internet problem - it seems like a form of link encapauslation/HC optimisation.

 > If you are grouping 10 VoIP packets (20 IP/8 UDP/12 RTP/20 payload), the tunnel needs 25 + 10x(2+60)=645bytes.
 > > Native traffic would need 10x60=600 bytes. So bandwidth increase is 7.5%. If you group 20 packets, bandwidth increase is 1265/1200= 5%
>
I think the extra byte overhead is not significant. Tunnel encpas in the CORE is common, using GRE, etc and adds more overhead.