Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 alpha 4/15/85; site ucbvax.ARPA
Path: utzoo!watmath!clyde!burl!ulysses!ucbvax!tcp-ip
From: tcp-ip@ucbvax.ARPA
Newsgroups: fa.tcp-ip
Subject: Re: TCP Timer
Message-ID: <8112@ucbvax.ARPA>
Date: Wed, 12-Jun-85 21:24:31 EDT
Article-I.D.: ucbvax.8112
Posted: Wed Jun 12 21:24:31 1985
Date-Received: Thu, 13-Jun-85 23:46:43 EDT
Sender: daemon@ucbvax.ARPA
Organization: University of California at Berkeley
Lines: 52

From: imagen!geof@su-shasta.ARPA


The first packet in the retransmission queue is the important one for
retransmission purposes, as Dave Plummer points out, since it is the
first packet that will be acked (and removed from the retrans. queue).

Dave's point about only retransmitting the first packet from the
retransmission queue is interesting.  I would be stronger than his
statement that this is "good enough" -- if a host always retransmits
everything on the retransmission queue, performance could be
drastically affected in certain situations.  Consider, for example, a
host that is transmitting through a gateway, and can send packets
faster than the gateway can forward them (perhaps a gateway from
Ether->Arpa).  Eventually, the gateway runs out of buffers and starts
to miss packets.  It is not uncommon to see a situation, for example,
where a gateway loses the fourth packet from every batch that is
blasted out by a particular host.

This sort of lossage can be seen at the destination host as well.  It
is a common cause of lost connections when a gateway is fragmenting
packets (in reverse of the above: the fast little gateway sends two
fragments very close together, and the big, slower host always misses
the second).  TCP performance can be affected similarly.

Dave's comment that retransmitting the first packet often results in
everything being acked seems to fit this model.  The first packet on
the retransmission queue (the first one that the foreign host didn't
ack) is probably the single packet that was lost.  [Interestingly,
Xerox' XNS SPP implementation also retransmits only the first packet on
the queue, for similar reasons (they have a serial-line gateway with
one packet buffer in it).]

Unfortunately, retransmitting only the first packet on the
retransmission queue, while it works, also has performance problems.
If the foreign host didn't lose just one packet, but lost a whole
string of them, TCP degenerates to a lock step (cf.  TFTP) protocol for
the rest of the string.  Over a very long-haul connection (e.g.,
satellite), this can cause a delay of seconds every time a packet is
lost.  Maybe in practise the number of packets lost in a row is
statistically close enough to 1 that this is not a problem.

I don't know a real answer to this problem (maybe someone else does...)
other than flow control (congestion control?) between a host the
gateway(s) that it is using on a particular connection (which is not
really possible in the TCP world -- say, wasn't someone asking if there
were any supporting arguments for that anti-TCP article in last month's
SigComm review?:-)).  Perhaps one might arrange to heuristically determine
in the sender that the Nth packet is reliably being lost, and throttle
back on the inter-packet time accordingly.  Sounds complicated.

- Geof