Subject: Upper limit on RTT?

From: Jamshid Mahdavi <[email-masked]>
Date: 24 Sep 1999 11:14:37 -0700

I stumbled across something interesting yesterday.  Most TCP
implementations use an initial timeout of something like 3 or 6
seconds.  If the SYN-ACK is not received in this time, congestion
avoidance is entered, with ssthresh set all the way down to 1 or 2
packets.

This means that for any path which is longer than this 3 or 6 second
timeout, a connection will be guaranteed to take a retransmission
timeout and do no slowstart.  Since these are exactly the connections
that need slowstart in order to quickly develop a large cwnd, it means
that network paths of this length will never get any reasonable
performance.

Interesting, huh?

The only solution which quickly comes to mind is to detect this using
our new DSACK (draft-floyd-sack-00.txt), and reset ssthresh to a large
value once you've detected the problem.

It might be good to add this to one of the PILC drafts...

--Jamshid

---

From: Kacheong Poon <[email-masked]>
Date: Fri, 24 Sep 1999 12:49:41 -0700 (PDT)

> value once you've detected the problem.

If TCP just ignores any retransmission during 3-way handshake in the context
of congestion detection.  So it will not set ssthresh to a lower value based
on the initial cwnd.  Then for the first data segment, RTO will probably be
large enough and there will be no retransmission (assuming there is no
congestion).  Slow start will continue and RTT will slowly converge to the
bigger value.  Is there any problem with this scheme?

							K. Poon.
							[email-masked]

---

From: Jamshid Mahdavi <[email-masked]>
Date: 24 Sep 1999 13:46:18 -0700

> bigger value.  Is there any problem with this scheme?

Well, spot checking a few different values seems to show that the
RTO is large enough to prevent a timeout on the first data packet.

Hrmmm, except that you apply Karn's algorithm and don't count your RTT
measurement from the SYN since you retransmitted it.  On the other
hand, you may have backed off the timer enough to prevent the timeout
on the first data packet (I think it depends on the exact timing, and
isn't guaranteed, though).

I'm a little uncomfortable with just ignoring a SYN which was actually
lost, since congestion signals are relatively infrequent and I think
you want to pay some mind to them.

I do wonder if there would be some merit in making the penalty for a
lost SYN be somewhat less severe than starting with a window of 1,
however...

--J