Lars, 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 dropped initial packets all that well. This may be okay since it rarely happens,but it's a problem if it becomes the norm.Exactly!
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 problem.
Most transport-related mechanisms assume that loss equals congestion, and they react by taking load off the (apparently) congested path.
...
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 stacks, etc.
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?
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