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

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

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

> -----Mensaje original-----
> De: FERNANDO PASCUAL BLANCO [mailto:[e-mail]]
> Enviado el: jueves, 17 de enero de 2013 14:39
> 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
> 
> 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
> Telefónica Global Resources
> Network Automation and Dynamization
> TECHNOLOGY PEOPLE GROUP
> F [phone]
> M [phone]
> [e-mail]
> 
> 
> 
> 
> On 17/01/13 13:16, "Jose Saldana" <[e-mail]> wrote:
> 
> >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
> >
> >> -----Mensaje original-----
> >> De: FERNANDO PASCUAL BLANCO [mailto:[e-mail]]  Enviado el:
> >>miércoles, 16 de enero de 2013 12:52
> >> 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 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.htm
> >> >> >> > l
> >> >> >> >
> >> >> >> > 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
> >> >> >> > > > -tc
> >> >> >> > > > mtf
> >> >> >> > > > /
> >> >> >> > >
> >> >> >> > > 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
> >
> 
> 
> ________________________________
> 
> 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