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

From: Mirko Sužnjević <[email-masked]>
Date: Thu, 13 Dec 2012 10:06:41 +0100

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/

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

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 13 Dec 2012 08:06:44 -0800

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