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

[FERNANDO PASCUAL BLANCO <[e-mail]>]

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
Telefónica Global Resources
Network Automation and Dynamization
TECHNOLOGY PEOPLE GROUP
F [phone]
M [phone]
[e-mail]




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

>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
>
>> -----Mensaje original-----
>> De: FERNANDO PASCUAL BLANCO [mailto:[e-mail]]
>> Enviado el: martes, 15 de enero de 2013 18:04
>> Para: [e-mail]; 'Dan Wing'; 'Mirko Sužnjević'; Julián
>>Fernández
>> Navajas
>> CC: [e-mail]
>> Asunto: Re: [tcmtf] Draft: Maximum Tolerable Delays when using Tunneling
>> Compressed Multiplexed Traffic Flows
>>
>> 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 [phone]
>> M [phone]
>> [e-mail]
>>
>>
>>
>>
>> On 17/12/12 12:25, "Jose Saldana" <[e-mail]> 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: [e-mail] [mailto:[e-mail]] En nombre
>> >> de Dan Wing Enviado el: viernes, 14 de diciembre de 2012 18:33
>> >> Para: [e-mail]; 'Mirko Sužnjević'
>> >> CC: [e-mail]
>> >> Asunto: Re: [tcmtf] Draft: Maximum Tolerable Delays when using
>> >> Tunneling Compressed Multiplexed Traffic Flows
>> >>
>> >> > -----Original Message-----
>> >> > From: Jose Saldana [mailto:[e-mail]]
>> >> > Sent: Friday, December 14, 2012 2:58 AM
>> >> > To: 'Dan Wing'; 'Mirko Sužnjević'
>> >> > Cc: [e-mail]
>> >> > 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: [e-mail] [mailto:[e-mail]] En
>> >> > > nombre de Dan Wing Enviado el: jueves, 13 de diciembre de 2012
>> >> > > 17:07
>> >> > > Para: 'Mirko Sužnjević'; [e-mail]
>> >> > > Asunto: Re: [tcmtf] Draft: Maximum Tolerable Delays when using
>> >> > > Tunneling Compressed Multiplexed Traffic Flows
>> >> > >
>> >> > > > -----Original Message-----
>> >> > > > From: [e-mail] [mailto:[e-mail]] On
>> >> > > > Behalf Of Mirko Sužnjevic
>> >> > > > Sent: Thursday, December 13, 2012 1:07 AM
>> >> > > > To: [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
>> >> > > > /
>> >> > >
>> >> > > 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
>> >> > > > ([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
>> >> > >
>> >> > >
>> >> > > _______________________________________________
>> >> > > tcmtf mailing list
>> >> > > [e-mail]
>> >> > > https://www.ietf.org/mailman/listinfo/tcmtf
>> >>
>> >> _______________________________________________
>> >> tcmtf mailing list
>> >> [e-mail]
>> >> https://www.ietf.org/mailman/listinfo/tcmtf
>> >
>> >_______________________________________________
>> >tcmtf mailing list
>> >[e-mail]
>> >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
>
>_______________________________________________
>tcmtf mailing list
>[e-mail]
>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