Subject: [rmcat] Requirements spec and Jitter

From: Randell Jesup <[email-masked]>
Date: Thu, 24 Jul 2014 13:21:50 -0400

Regarding why Jitter doesn't appear as a requirement in the draft:

I think delay variation (and perhaps more importantly, delay response to 
cross traffic changes) will be seen in the responses to the evaluation 
criteria.  I don't think we could say much in the requirements - and 
keeping delay variation low implies living with higher delay on average; 
variation as low-as-possible would mean much higher delay (generally). 
So it competes with the primary goal.  Also, delay jitter is normally 
absorbed by the jitter buffers - the net result is that if we reduce 
transfer jitter, the jitter buffer will contract (but generally not by 
as much as we reduce transfer jitter), again leading to longer 
end-to-end media delays. Getting the data to the jitter buffer with as 
low a delay as possible generally lets the jitter buffer and adaptive 
resampling do it's job; and the application can tune those to provide 
the level of user-visible delay variation it wants.  There are cases 
where large packet-to-packet delay can cause a jitter buffer to run 
larger than you'd like, but this gets deep into the specific design of 
the jitter buffer, and would tie the spec to a specific definition of a 
jitter buffer if we try to lock it down.

So, I think we should keep with our primary goal, and not try to mix 
jitter control explicitly into it, and let the jitter buffers and other 
application tools decide how to process the data.

(I wouldn't say we don't care *at all*, but it's a lower level of 
concern, and I don't think any proposed algorithm would fail to provide 
a reasonable delay profile over time - and so I wouldn't make it a 
requirement, and I don't think we should spend time arguing over what's 
"reasonable" or what are hard requirements when I don't think it will 
even come into play.  It's like "Fairness".)

I'll also note that "Jitter" usually implies low-duration events; and we 
care mostly about total mouth-to-ear delay - and medium-to-long term 
measures of delay are important.

-- 
Randell Jesup -- rjesup a t mozilla d o t com

---

From: Colin Perkins <[email-masked]>
Date: Thu, 24 Jul 2014 16:21:06 -0400

So, I think the requirement should be low overall latency. From the transport perspective, the most important component of that is transit delay, I agree, but transit delay variation (i.e., jitter) does affect the overall latency, and I think should be mentioned. 

Colin

On 24 Jul 2014, at 13:21, Randell Jesup <[email-masked]> wrote:

> I think delay variation (and perhaps more importantly, delay response to cross traffic changes) will be seen in the responses to the evaluation criteria.  I don't think we could say much in the requirements - and keeping delay variation low implies living with higher delay on average; variation as low-as-possible would mean much higher delay (generally). So it competes with the primary goal.  Also, delay jitter is normally absorbed by the jitter buffers - the net result is that if we reduce transfer jitter, the jitter buffer will contract (but generally not by as much as we reduce transfer jitter), again leading to longer end-to-end media delays. Getting the data to the jitter buffer with as low a delay as possible generally lets the jitter buffer and adaptive resampling do it's job; and the application can tune those to provide the level of user-visible delay variation it wants.  There are cases where large packet-to-packet delay can cause a jitter buffer to run larger than you'd like, but this gets deep into the specific design of the jitter buffer, and would tie the spec to a specific definition of a jitter buffer if we try to lock it down.
> 
> So, I think we should keep with our primary goal, and not try to mix jitter control explicitly into it, and let the jitter buffers and other application tools decide how to process the data.
> 
> (I wouldn't say we don't care *at all*, but it's a lower level of concern, and I don't think any proposed algorithm would fail to provide a reasonable delay profile over time - and so I wouldn't make it a requirement, and I don't think we should spend time arguing over what's "reasonable" or what are hard requirements when I don't think it will even come into play.  It's like "Fairness".)
> 
> I'll also note that "Jitter" usually implies low-duration events; and we care mostly about total mouth-to-ear delay - and medium-to-long term measures of delay are important.
> 
> -- 

-- 
Colin Perkins
http://csperkins.org/