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

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

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