Subject: Re: Upper limit on RTT?

From: Vernon Schryver <[email-masked]>
Date: Mon, 27 Sep 1999 19:32:37 -0600 (MDT)

> From: Markus Buchhorn <[email-masked]>

> >> How many paths have 3-6 second RTT's? 
> >> 10 geo-sync satellite hops is more than I've heard about lately.
>
> How about a path involving a dial-on-demand link ? Modem negotiation can be
> much longer than 3-6 seconds...

Yes, but that's not an RTT, or at least not an RTT that keeps the
congestion window from opening at a reasonable rate when the connection
is finally established, is it?

Vernon Schryver    [email-masked]

---

From: Jamshid Mahdavi <[email-masked]>
Date: 29 Sep 1999 09:32:11 -0700

> is finally established, is it?

Actually, I believe that the way most implementations today work, if
the SYN is delayed, the sender takes the timeout and doesn't
subsequently do slowstart.

From the recent messages, it certainly sounds like this qualifies as a
"performance implication of a link characteristic" :-)

My take is that there are two interesting messages we want to get out:

1. Link designers: Avoid very large delays, especially on connection
setup, when designing a technology.

2. TCP implementors: Don't reduce the initial SYN timeout too much
(where too much probably means below 3 seconds) if you want any hope
of achieving large windows/bandwidth on a high delay pipe.

Also, do we have something like Vernon's comment about packet sizes
for slow links in the "thin" draft?  It might be good to include some
rule of thumb, like no more than 200msec for a packet transmission
time, to help people choose MTU.  (200msec is a nice number, because
it will enable most delayed ACK implementations to still function
correctly).

Any suggestions about which documents all this should go in?

--J