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

From: "Jose Saldana" <[email-masked]>
Date: Mon, 17 Dec 2012 12:25:38 +0100

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