Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!uwm.edu!cs.utexas.edu!uunet!ingr!b11!griffin From: griffin@b11.ingr.com (Tommy Griffin) Newsgroups: comp.protocols.tcp-ip Subject: telnet and pc's Message-ID: <8285@b11.ingr.com> Date: 5 Jul 90 20:16:04 GMT Organization: Intergraph Corp. Huntsville, AL Lines: 62 We're experiencing some difficulty communicating between our workstations and PCs using Telnet over TCP/IP. The PCs are running Sun's PC/NFS product through the 3-Com Ethernet card. The problem occurs when a Telnet session has been established from a PC to a workstation, and the workstation is generating a continuous stream of output to be displayed by the PC. The PC begins to display the output, but instead of displaying a continuous stream of data, new data is displayed at intermittent intervals with 1-20 second delays between bursts of output. The delay usually ramps up to 20 seconds and stays there. The problem seems to be caused by the PC's inability to receive and/or process Ethernet/TCP frames which arrive within 5 milliseconds of each other. Our workstation sends output to the PC in TCP frames carrying 64 bytes of data. The 512 byte TCP window offered by the PC's TCP allows us to send up to 8 frames inside one window, so these frames can arrive with very little inter-frame spacing. When the PC drops a frame, we have to retransmit the data that was lost. The Jacobson algorithm in our implementation of TCP causes us to *DOUBLE* our retransmission timer each time we have to retransmit data. We eventually increase the retransmission timer to its maximum value, 20 seconds, which explains why we're seeing bursts of data every 20 seconds. We have some Sun workstations here, and a few PCs running Sun's PC/NFS, and when we Telnet from the PCs to the Suns we don't see any delay on continuous output from the Suns to the PCs. So, we got out our Ethernet Sniffer to figure out what the Suns are doing that we aren't. It seems that the Sun workstations somehow determine that they're communicating with Sun PC/NFS on a 3-Com card, because they only allow one TCP frame to be transmitted to the PC at a time. They send a frame, and wait for an acknowledgement (or a retransmission timeout), then send another frame, and so on. This occurs even if the frame contains less data than the offered window size. When we Telnet between Suns, or from Suns to our workstations, the Suns transmit many small TCP frames containing data in the offered TCP window before waiting for an acknowledgement. We would like to communicate effectively between our workstations and PCs with the Sun PC/NFS Telnet through the 3-Com Ethernet controller. What we would like to know is how does the Sun workstation TCP implementation determine that it is talking to 3-Com PC/NFS? Does it look at the Ethernet address to determine that the board came from 3-Com? Is there something special in the TCP SYN packets that they key on? Any light that can be shed upon this matter would be greatly appreciated. Tom Griffin griffin@ingr.com -- ______________________________________________________________________________ Tommy Griffin