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

From: "Jose Saldana" <[email-masked]>
Date: Fri, 14 Dec 2012 11:58:03 +0100

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.

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?

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

---

From: Mirko Sužnjević <[email-masked]>
Date: Fri, 14 Dec 2012 13:43:52 +0100

Hello,
Just a quick response. As a response on the first question: I am not aware of any such mechanisms being employed in games, but as Jose said a great majority of games has proprietary sources. 
As for the other question, yes we might be better off reporting RTT in terms of games, as most players just look at "ping" and that is RTT. Maybe even from a overall standpoint it would be better to report RTT for the sake of simplicity and clarity of the formulas?
Mirko

-----Original Message-----
From: Jose Saldana [mailto:[email-masked]] 
Sent: Friday, December 14, 2012 11: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.

If we think RTT:

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.

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?

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,
> >
> >
> >
expect
but
and
> 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?
>

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 14 Dec 2012 09:32:41 -0800

> 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
> 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.

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.

> 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