Re: [RRG] Why delaying initial packets matters

[Marshall Eubanks <tme@multicasttech.com>]

On Feb 8, 2008, at 8:43 PM, David Conrad wrote:

> Stig,
>
> On Feb 8, 2008, at 1:22 AM, Stig Venaas wrote:
> > I'm sure there could be other ways. Anyway, I believe such delays  
> > will
> > require changes in applications and/or host stacks.
>
>
> I'm not necessarily disagreeing, but before looking at potential  
> solutions, can you be a bit more specific in what you believe will  
> require changes?  Let's say you have a system that imposes a (say)  
> 500 ms delay on the first packet of a flow (but no significant  
> change in subsequent packets).  Would you see a requirement for  
> changes in UDP-based applications? Or would the changes just need  
> to be in TCP-based applications?

It wouldn't necessarily change the kernel stack, but a 500 msec delay  
on every stream start would sure make video channel changing slow,.  
There is a lot of work going into making channel changing fast, and  
that work would become moot in this case.

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.

Regards
Marshall


> Thanks,
> -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


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