Re: [RRG] Why delaying initial packets matters

[Stig Venaas <stig.venaas@uninett.no>]

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