On 04/20/2012 09:13 AM, Jim Gettys wrote:
On 04/20/2012 08:41 AM, Piers O'Hanlon wrote:
On 20 Apr 2012, at 13:32, Michael Welzl wrote:
On Apr 20, 2012, at 2:23 PM, Jim Gettys wrote:
On 04/20/2012 07:55 AM, Mirja Kuehlewind wrote:
Hi Randell,
I didn't follow the whole discussion but regarding LEDBAT we have a TARGET delay of max. 100ms. That means you can choose a smaller one. We've chosen 100ms as a max as there is an ITU recommendation that 150 ms delay is acceptable for most user voice applications and we wanted for sure stay below that. 100 ms + 75ms speed of light delay across the US (or equivalent across Europe, for example) + 100ms at the receiving end....
Of course, it's even worse between continents, even without broken networks.
Not so nice.... Not argueing about your point here (I agree that we have to fix the edge), but: LEDBAT is an end-to-end mechanism, so I think that the 100ms reflect the total measured end-to-end delay.
I think LEDBAT's target is the relative delay (i.e. from queues) - It's not clear how it would measure the total end-to-end delay.
Sorry, I wasn't really clear enough. It may be that LEDBAT will stop adding at 100ms; my point is that even with "traditional" drop-tail queues sized at the "traditional" 100ms level, you have to think about the fact there are two ends. Either/both may be filled, and filled by even a single TCP connection. So the total delays are as I lay out: you can trivially get to 300ms without trying hard under some circumstances, twice the ITU max recommendation for telephony, and about 10x human perception time for other applications.
And the variable bandwidth case makes this all much worse (both Powerboost or equivalent in the broadband connections, and tremendously more so in wireless. Fixed size, unmanaged, drop tail queues have *got* to go.
To "fix" this disaster, we have to make the edge "smarter", probably with a combination of some sort of "fair" queueing/diffserv *and* AQM. This is that tack that some of us are taking in Dave Taht's CeroWrt home router work. Once we've done that, delay sensitive AQM's stop being effective, since the delays drop to relative zero. I meant to day delay sensitive congestion control algorithms, of course... - Jim
So people need to think about how delay sensitive algorithms such as LEDBAT compete with other traffic in the absence of delays that trigger them. Because any fix removes the very delay that they use to try to get out of the way. - Jim