Chapter 24

p. 340

There is an up-to-date table on support of Path MTU discovery, timestamps, window scale etc. in various operating systems at http://www.psc.edu/networking/perf_tune.html.

p. 344

Since ATM does not do ``store-and-forward'' at the TCP/IP 2 level, its use decreases the latency, especially across large WANs.

p. 344

Stevens does not show ``gigabit over satellite'', but this is now achievable, and has a bandwidth-delay product of 62Mb. Satellite links have many other problems, described in RFC 2488.

p. 347

Note that there is a difference between sending (in the initial SYN) a shift count of 0 (a scale factor of $2^0=1$) and not sending a window scale option at all. The former indicates that the sender will accept and understand window scaling from the other end, though it does not wish to use it. The latter says that the sender does not understand window scaling, and so the other end MUST NOT send such an option. RFC 1323 says ``Thus a TCP that is prepared to scale windows should send the option, even if its scale factor is 1'' (i.e. what is sent is 0, since $2^0=1$).

p. 349

Note, however, the timestamps, because they are TCP options, prevent TCP/IP header compression (p. 25 and notes thereto) and therefore are unhelpful on slow links. Slow links do not normally need the accuracy of RTT estimation that timestamps provide, and do not need PAWS protection (next section). Fortunately, slow links tend to occur in situations like dial-up from home, where most connections (certainly HTTP connections) are initiated from the home end, and therefore if this end does not send timestamps, they will not be used.

p. 354

It is astonishing how ``Ethernet can only support 100Kbytes/sec'' remains in the folklore, even though it is well-exploded by now. Equally, the ``fat pipes'' across the Atlantic are normally full, so high-speed networking is a reality.