Trailers

An application (like FTP) sends a string of octets to TCP which breaks it into chunks, and adds a TCP header. TCP then sends blocks of data to IP which adds its own headers and ships the packets over the network. All this prepending of the data with headers causes memory moves in both the sending and the receiving machines. Someone got the bright idea that if packets were long and they stuck the headers on the end (they became trailers), the receiving machine could put the packet on the beginning of a page boundary and if the trailer was OK merely delete it and transfer control of the page with no memory moves involved. The problem is that trailers were never standardized and most gateways don't know to look for the routing information at the end of the block. When trailers are used, the machine typically works fine on the local network (no gateways involved) and for short blocks through gateways (on which trailers aren't used). So TELNET and FTP's of very short files work just fine and FTP's of long files seem to hang. On BSD 4.2 trailers are a boot option and one should make sure they are off when using the Internet. BSD 4.3 negotiates trailers, so it uses them on its local net and doesn't use them when going across the network.

Retransmissions

TCP fires off blocks to its partner at the far end of the connection. If it doesn't receive an acknowledge- ment in a reasonable amount of time it retransmits the blocks. The determination of what is reasonable is done by TCP's retransmission algorithm. There is no correct algorithm but some are better than others, where better is measured by the number of retransmis- sions done unnecessarily. BSD 4.2 had a retransmission algorithm which retransmitted quickly and often. This is exactly what you would want if you had a bunch of machines on an ethernet (a low delay network of large bandwidth). If you have a network of relatively longer delay and scarce bandwidth (e.g. 56kb lines), it tends to retransmit

too aggressively. Therefore, it makes the networks and gateways pass more traffic than is really necessary for a given conversation. Retransmis- sion algorithms do adapt to the delay of the network

-18-

after a few packets, but 4.2's adapts slowly in delay situations. BSD

4.3 does a lot better and tries to do the best for both worlds. It fires off a few retransmissions really quickly assuming it is on a low delay network, and then backs off very quickly. It also allows the delay to be about 4 minutes before it gives up and declares the connection broken.

-19-

Appendix A References to Remedial Information

Quaterman and Hoskins, "Notable Computer Networks", Communications of the ACM, Vol 29, #10, pp. 932-971 (October, 1986).

Tannenbaum, Andrew S., Computer Networks, Prentice Hall, 1981. Hedrick, Chuck, Introduction to the Internet Protocols, Anonymous

FTP from topaz.rutgers.edu, directory pub/tcp-ip-docs, file tcp-ip- intro.doc.

-20-

Appendix B List of Major RFCs

RFC-768 User Datagram Protocol (UDP) RFC-791 Internet Protocol (IP) RFC-792 Internet Control Message Protocol (ICMP) RFC- 793 Transmission Control Protocol (TCP) RFC-821 Simple Mail Transfer Protocol (SMTP) RFC-822 Standard for the Format of ARPA Internet Text Messages RFC-854 Telnet Protocol RFC-917 *Internet Subnets RFC-919 *Broadcasting Internet Datagrams RFC-922

*Broadcasting Internet Datagrams in the Presence of Subnets RFC-940

*Toward an Internet Standard Scheme for Subnetting RFC-947 *Multi- network Broadcasting within the Internet RFC-950 *Internet Standard Subnetting Procedure RFC-959 File Transfer Protocol (FTP) RFC-966

*Host Groups: A Multicast Extension to the Internet Protocol RFC-988

*Host Extensions for IP Multicasting RFC-997 *Internet Numbers RFC- 1010 * Assigned Numbers RFC-1011 * Official ARPA-Internet Protocols

RFC's marked with the asterisk (*) are not included in the 1985 DDN Protocol Handbook.

Note: This list is a portion of a list of RFC's by topic retrieved from the NIC under NETINFO:RFC-SETS.TXT (anonymous FTP of course).

The following list is not necessary for connection to the Internet, but is useful in understanding the domain system, mail system, and gateways:

RFC-882 Domain Names - Concepts and Facilities RFC-883 Domain Names - Implementation RFC-973 Domain System Changes and Observations RFC-974 Mail Routing and the Domain System RFC- 1009 Requirements for Internet Gateways

-21-

Appendix CContact Points for Network Information Network Information Center (NIC)

DDN Network Information Center SRI International, Room EJ291 333 Ravenswood Avenue Menlo Park, CA 94025 (800) 235-3155 or (415)

859-3695 NIC@SRI-NIC.ARPA

NSF Network Service Center (NNSC)

NNSC BBN Laboratories Inc. 10 Moulton St. Cambridge, MA 02238 (617) 497-3400 NNSC@NNSC.NSF.NET

-22-

Glossary core gateway

The innermost gateways of the ARPAnet. These gateways have a total picture of the reacha- bility to all networks known to the ARPAnet with EGP. They then redistribute reachabil- ity information to all those gateways speak- ing EGP. It is from them your EGP agent (there is one acting for you somewhere if you can reach the ARPAnet) finds out it can reach all the nets on the ARPAnet. Which is then passed to you via Hello, gated, RIP....

count to infinity

The symptom of a routing problem where routing information is passed in a circular manner through multiple gateways. Each gate- way increments the metric appropriately and passes it on. As the metric is

passed around the loop, it increments to ever increasing values til it reaches the maximum for the routing protocol being used, which typically denotes a link outage.

hold down

When a router discovers a path in the network has gone down announcing that that path is down for a minimum amount of time (usually at least two minutes). This allows for the pro- pagation of the routing information across the network and prevents the formation of routing loops.

split horizon

When a router (or group of routers working in consort) accept routing information from mul- tiple external networks, but do not pass on information learned from one external network to any others. This is an attempt to prevent bogus routes to a network from being propagated because of gossip or counting to infinity.

-23-