[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RRG] Why delaying initial packets matters
On Feb 18, 2008, at 6:12 AM, Lars Eggert wrote:
On 2008-2-17, at 21:31, ext Stig Venaas wrote:
My experience is that some applications don't handle delayed or
initial packets all that well. This may be okay since it rarely
but it's a problem if it becomes the norm.
Data? While I'm perfectly willing to accept this is the case (really),
I would prefer to understand what these applications are, why they are
the way they are, and what (if anything) can be done to mitigate the
Most transport-related mechanisms assume that loss equals
congestion, and they react by taking load off the (apparently)
It wouldn't be a good idea from a congestion control perspective,
because the initial phase of a connection is exactly when the
transport protocols have the least knowledge about the path
characteristics (bandwidth, delay, etc.), because they have no
sampled path state, so that's when they need to be most conservative.
Indeed. And since they have no sampled path state, being the most
conservative typically means having a timeout at some fixed value,
potentially exponentially increasing that timeout after the
retransmit. I'm not sure how I see this needing to change if you add a
few hundred more msec delay for the first packet.
DNS applications are a good case to look at, as is web traffic, SIP
DNS isn't a particularly good case (IMHO) as it isn't all that
sensitive to initial delay. Web traffic (particularly due to "link
dense" web pages) might be. SIP stacks, maybe, but I don't see why
they'd be all that sensitive to initial delay (since people are
already used to dealing with significant delay during call setup).
Maybe ENUM-related services?
to unsubscribe send a message to firstname.lastname@example.org 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