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?
Right, I agree we need to look into the possible issues first. I can see at least 3 possible theoretical effects of delaying the first packet. 1. First packet is delayed, packets are kept in order 2. First packet is delayed, subsequent packets may arrive first 3. All initial packets dropped Which of these apply depends on how the application protocol or transport protocol behaves, as well as the underlying system. Looking at 1. Assuming you have to wait 500ms for some mapping to be in place. If you have a simple UDP based protocol with a retransmission time well above 500s, then it may not be an issue at all, apart from perhaps a user experiencing longer delay. If the retransmission time is less than 500ms + RTT, then you will get retransmissions as well. If the initial packets are buffered, then you may get additional load on some server, having to process both the initial and retransmitted packets. Regarding case 2. I think it should be possible to avoid reordering. Once a mapping is in place, it might be that some buffered packets are delivered after some others that are forwarded. I'm not so sure reordering is much of a problem though. The 3rd case is what I had in mind when I posted. I believe many UDP based applications have timeouts and retransmit only after a few seconds. In this case, dropping the initial packet will result in users experiencing far too long delays in my opinion. It's not necessarily good if applications retransmit in less than a second either (too short timeouts may in other cases result in servers receiving the same request multiple times). I also think there might be some other effects of this. E.g. if you have two servers A and B where an application should prefer A over B, it might be that when initial packets to A are delayed/dropped, it will try B instead. Possibly marking A as bad/dead and continue using B that is not preferred. Well, this is still more or less speculation. I suppose what should be done, is to study some common applications or protocols and see what the effects would be. An obvious first candidate would be DNS I think. Stig > > Thanks, > -drc > -- to unsubscribe send a message to [EMAIL PROTECTED] 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
