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:48:46 +0100

Dan,

Thanks for your feedback.

1) Regarding the question of 400 ms OWD for VoIP: If ITU says that delays
between 150 and 400 ms are acceptable, perhaps we could distinguish between
high-quality and non-high-quality VoIP. Does this make sense? The users of
some free-of-charge VoIP services may tolerate higher delays.

2) Regarding the jitter buffer, currently the draft doesn't talk about it.
So I think we should include some reference to that buffer. For online
games, we cannot talk about it, since the implementation is not (usually)
public, but in VoIP it exists.

What happens with Remote Desktop applications?

Mirko, do you know if something similar to jitter buffer exists for any game
genre?

And with respect to the OWD estimation, I send another mail.

Thanks,

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: Julián Fernández-Navajas <[email-masked]>
Date: Fri, 14 Dec 2012 13:57:48 +0100

Hello,
I agree with Jose in order to distinguish between high and non high 
quality VoIP.
The ITU-T Rec. G.114 defines several levels of user acceptance: Users 
very satisfied (0-200 ms OWD total value of one-way
delay from mouth-to-ear), users satisfied (200-300ms), some user 
dissatisfied (300-400ms), many users dissatisfied (400-500ms) and Nearly 
all users dissatisfied (>500ms).
Perhaps it would be fine define three levels for the OWD in VoIP: high 
quality (<200ms), acceptable quality (200-300ms) and no acceptable 
quality (>300ms)
Julián

---

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

> Of Julián Fernández-Navajas
> Sent: Friday, December 14, 2012 4:58 AM
> To: [email-masked]
> Subject: Re: [tcmtf] Draft: Maximum Tolerable Delays when using
> Tunneling Compressed Multiplexed Traffic Flows
> 
> Hello,
> very satisfied (0-200 ms OWD total value of one-way delay from mouth-to-
> ear), users satisfied (200-300ms), some user dissatisfied (300-400ms),
> many users dissatisfied (400-500ms) and Nearly all users dissatisfied
> (>500ms).
> quality (>300ms) Julián

That sounds like a good place to start.

Mouth-to-ear delay is the total delay, and we cannot consume the total
delay in the network -- there are other delays that consume part of the
delay budget.  Those include the sender's codec delay (which varies 
depending on compression and speed of its processor) and the packetization 
interval (the sender does not send a continuous stream of bits).  On
the receiver we have the jitter buffer (~20-60ms or more) and its codec 
(which varies depending on compression and speed of its processor).

-d

> > 1) Regarding the question of 400 ms OWD for VoIP: If ITU says that
> > delays between 150 and 400 ms are acceptable, perhaps we could
> > distinguish between high-quality and non-high-quality VoIP. Does this
> > make sense? The users of some free-of-charge VoIP services may
> tolerate higher delays.
> >
> > games, we cannot talk about it, since the implementation is not
> > (usually) public, but in VoIP it exists.
> >
> > Mirko, do you know if something similar to jitter buffer exists for
> > any game genre?
> >
> >> 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,
> >>>
> >>>
> >>>
> >> 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?
> >>