[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