CLIFF@CMSA.BERKELEY.EDU (Cliff Frost {415} 642-5360) (09/20/90)
> (Why is it the nasty comments are published, and the nice ones are sent > privately? This complaint smacks of the pot calling the kettle black, but since you ask, I asked you publically because you failed to answer either of the entirely neutral requests for information I sent you privately. Thank you for *finally* publishing some information. Cliff Frost
09998WAS%MSU@PUCC.PRINCETON.EDU ("Bill.Simpson") (09/21/90)
There being 5 requests for the information, I suppose that it's worthwhile to post this to the group at large. ---- ---- ---- ---- ---- First, this implementation does not bundle a reply ACK with the reply data, resulting in 2 packets. An ACK is sent right away when the PSH flag is set. This behaviour results in slow FTP startup times, and very slow throughput for short transfers such as dir LISTs. This is cited as a poor implementation practice in RFC1122 at 4.2.2.14. Similarly, the first data packet is sent separately from the handshake ACK. Minor, but significant and unexplained. ---- ---- ---- ---- ---- Secondly, there is a serious problem with the retransmission timer. On startup of successive file transfers, the host-host rtt does not seem to be remembered (as other implementations do). The timer always starts too fast, and takes several timeouts before it reaches a reasonable value. (Other implementations reach this value after 1 timeout, or 2 at most.) Then, it continues to increment! Timeouts later in the transfer come at intervals of 20 or 40 seconds, even after a smooth transmission for dozens of packets! ---- ---- ---- ---- ---- Thirdly, less than MSS sized packets are transmitted. (I opine that this is due to an error in the congestion avoidance algorithm, as it only occurs when the window:MSS ratio is greater than 2.) ---- ---- ---- ---- ---- Fourthly, a "persist" timer kicks in every 5 seconds, and flushes whatever happens to be in the buffer. (Yet another source of less than MSS sized packets.) This occurs even though the link was continuously transmitting. Since the rtt was ~2.4 seconds, this annoying source of small packets put a serious dent in the throughput. ---- ---- ---- ---- ---- Fifthly, the link itself times out after 10 minutes from startup (default). I could understand if that was for an *idle* link (10 minutes since last packet transmission), but in the middle of an active transfer?!? ---- ---- ---- ---- ---- Sixthly, the higher level protocols (FTP, SMTP) do not properly treat the TCP connection as a stream. Instead -- at least on the control connection -- the remainder of a PSHed segment is discarded. That is, PSHed segments are treated as unit records! When a properly functioning TCP combines PSHed segments per 4.2.2.2, they are not properly processed on the IBM end, resulting in a hung connection. ---- ---- ---- ---- ---- Relevant RFC1122 cites: 4.2.2.2, 4.2.2.14, 4.2.2.15, 45.2.2.17, 4.2.3.1, 4.2.3.2, 4.2.3.4, 4.2.3.5, 4.2.3.6. Hope this clears up any questions the various flamers have had! (Why is it the nasty comments are published, and the nice ones are sent privately? Not that I didn't appreciate getting them, mind you! Thanks all!) Bill Simpson 09998was@msu.bitnet 09998was@ibm.cl.msu.edu