[Freeciv-Dev] Re: Network bandwidth, and other things.

[Jason Dorje Short <vze49r5w@xxxxxxxxxxx>]

Christian Knoke wrote:
> On Wed, Nov 06, 2002 at 02:40:40PM -0500, Jason Dorje Short wrote:
>
> > Christian Knoke wrote:
> >
> >
> > > What happens with TCP/IP, when a single packet got lost? I think, in the
> > > first place, _nothing_ happens. Neither of both endpoints of the connection
> > > gets aware of this (But I may be wrong here!). Only after another packet is
> > > sent in the same direction, or a specific amount of time passes, the
> > > receiver gets notified of this and resends the packet.
> > After each packet sent an "ACK" packet is sent in return.  If the ACK 
> > does not arrive in a reasonable timeframe (which is a very difficult 
> > subject in itself), the packet is resent.
>
> Yes, that's the question! If the timeframe is 10 sec or greater, the above
> applies.
>
>
> > So, this is not a problem.
>
> Not?
Right, not.

First of all, the time frame isn't 10 seconds.  Even on a modem 
connection you should have a RTT of about 1 second.  I can't imagine the 
client would wait more than 2 seconds before resending.  But again, if 
the first packet didn't get through there's no guarantee a second one will.
Say you sent a ping every second, and a packet is dropped but then the 
ping gets through.  Note that it's just as likely to be the other way 
around (see below).  Now the server responds to the ping - but it 
doesn't say "I got the ping but not the packet before", all it says is 
"I haven't yet gotten the packet before".  The client may use this 
information to resend the previous packet, but most likely it will not - 
after all, if its expected time to have received the ACK hasn't passed 
yet, why should it expect to have received one?
Now say the ping from immediately *before* you sent the movement packet 
is dropped.  Now you have to wait 2 (or 10) seconds for the ping packet 
to be resent, before the server can use the movement packet.  So you've 
nearly doubled the frequency of having to wait.
> Good point, but if a ping packet gets losts, you can go on after 2 seconds.
> If a move packet is lost, you'll sit and wait ... Nothing you can do. You
> *can't* just press that cursor key again. If you have bad luck, you wait
> long.
See above.  Losing the ping packet may not mean anything itself, but it 
means no other packets can get through until the ping does.
> > I can imagine (but can't say definitively) why the above behavior might 
> > happen.  If you're on a slow (high-latency) connection, then the 
> > round-trip-time from client to server will be high.  In this case the 
> > packet will take longer to be sent.  And if the packet is lost multiple 
> > times (which is probably likely - packets usually aren't just dropped 
> > randomly but are dropped because somewhere a server's buffer is too big) 
> > then the wait will be extended.
>
> Ok, this may be true, that a server's buffer is overrun. But as soon as
> one packet gets through (I think), TCP will correct the drops (by 
> resending) and you'll be fine 2 sec later.
See above.  Just because one packet gets through doesn't mean the sender 
knows the others didn't.  They might still be en route - the packets are 
not guaranteed to arrive in order.  Only after a sufficient time has 
passed to guess that the packet didn't get through will it be resent. 
The system used to guess is dependent on which implementation of TCP 
you're using (i.e. your OS) - and while you may be able to try to fool 
it in some ways, this is unlikely to be portable.
The conclusion is: TCP performance is really awful over a high-latency 
connection.  It is also really awful when any significant portion (even 
just 1%) of packets get dropped.  And by resending packets, it is likely 
to congest the network even more causing the drop rate to increase.
jason