[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RRG] Why delaying initial packets matters
Dear David;
On Feb 9, 2008, at 12:50 PM, David Conrad wrote:
Marshall,
Thanks for the response.
On Feb 9, 2008, at 6:26 AM, Marshall Eubanks wrote:
It wouldn't necessarily change the kernel stack, but a 500 msec
delay on every stream start would sure make video channel changing
slow,.
I'd be ecstatic if my Tivo could change channels faster than 3000
msecs (or could do it without getting the wrong channel 15% of the
time, sigh), but that's neither here nor there.
There is a lot of work going into making channel changing fast,
and that work would become moot in this case.
Right.
Of course, a lot would depend on what is meant by "flow" above. If
only the first packet from a /24 to a end user is
delayed, that would change little at the application layer.
All channels would come from of the same address block?
I was trying to guess what was really meant by "flow" in this
context. It seems to me that the
worse case is per "tcp flow" and the best case is "every packet from
some address block to another address block
in some (longish) time." (By "TCP flow" you could substitute "RTP
SSID and port" for UDP.)
In most cases, DNS is involved in the start of an interaction with a
remote site, and that can also take
a substantial time... the first time. If what's at issue is something
with similar characteristics to DNS,
I think that you have an existence proof that it could be accepted.
What are the current delay assumptions?
Well, it depends. A lot of (all?) players have a multi-second time
out, so any multi-second delays will cause
real problems. Some players use non reception of packets as a sign of
blockage, so they may switch bandwidth or
from UDP to TCP if the first packets take too long to arrive.
More seriously, channel changing goals are typically a few 100 msec
at most, including RTT. Any longer is
supposed to annoy users. Whether or not that is supportable is
another question - but I think a large
section of the streaming / broadcast community would object strongly
if that applies to every stream.
Regards
Marshall
Regards,
-drc
--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg