chris@umcp-cs.UUCP (Chris Torek) (06/03/85)
Background: the Computer Science Center has a new toy, the AT&T ISN (Information Systems Network, I think). The ISN will (among other things) connect two RS232 lines as a virtual circuit, running up to 19200 baud over rather long distances. We have managed to get two estranged Vaxen connected in this manner, and I have installed a serial line TCP/IP interface. Amazingly enough, it all works---as long as I keep the interface MTU at 100 bytes or less. The problem: sending more than 100 bytes at a time over the ISN virtual circuit just doesn't work right. If I run ping (a program that uses raw sockets to send ICMP echoes) and send 100 bytes at a time, the round trip delay is consistently under 250 milliseconds. However, if I send 101 or more bytes, the initial delay is reasonable, then the delays increase and continue to increase. Restarting ping with small packets starts at the previous delay, and the times slowly decrease, eventually returning to the normal < 250ms round trip time. Basically, if you send more than 100 bytes at a time, you lose. The smallest of delays between each 100 byte send is sufficient to make everything work. The question (finally): does anyone Out There know about ISNs and how to get around this problem?* TCP headers are chewing up 40% of the available bandwidth of the serial link, and that isn't really nice.... (I'm n-squared steps removed from the actual operation of the ISN---and the documentation---so if the answer is obvious, tell me anyway, since this is probably the only way I'll ever find it.) ----- *Truly ugly hacks like inserting ttrstrt timeouts in the DH and DMF drivers don't count. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 4251) UUCP: seismo!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@maryland