Chapter 18

p. 236

Though MSS is not ``negotiated'', the sender may send less than the MSS advertised by the recipient, e.g. due to Path MTU discovery (p. 340). Therefore algorithms like delayed acknowledgements (p. 277) must count segments, not bytes in units of MSS.

Equally, though Stevens implies that MSS=MTU$-$40, the increasing use of TCP options (especially Timestamp, see section 24.5) means that this is not always the case⁴⁸. RFC 2525 (section 2.18) points out that failure to allow for this, especially in the presence of Path MTU discovery (section 24.2) can result in a complete failure to transmit. I have seen Windows 2000 systems advertise an MSS of $1380=1500-60-60$, and refuse to send larger segments than this, even though the other end advertises 1460.

p. 241

Note that this diagram incorporates the corrections from RFC 1122 to the original diagram from RFC 793.

Not all transitions in this diagram are supported by all applications. Barry Margolin (barmar@genuity.com) writes as follows.

Both of these issues (LISTEN to SYN_SENT transition and simultaneous open) are probably more applicable to peer-peer protocols than client-server protocols. An example might be BGP (note: it doesn't make use of the above features, but it could have been designed to), where the neighboring routers establish TCP connections with each other in order to exchange routing information; if it were specified to use the same port as both the source and destination (which would not be unreasonable, since there's no need for multiple connections between the same two peers, except for the TIME_WAIT delay between reuse of the same ports) then a simultaneous open would occur if both peers tried to connect to the other at the same time. And a LISTEN to SYN_SENT could happen if one router first tries listening for an incoming connection, and when a timeout occurs it then tries to connect it.

p. 243

RFC 793's specification of the MSL as 2 minutes is more honoured in the breach than in the observance. [8] shows that over half of webservers have MSL as 15 seconds, over a third have it as zero, and only about 10% have it as 2 minutes.

p. 246

The MSL quiet time is enforced by no operating system that the readers of comp.protocols.tcp-ip know. For a client, this is not too serious, but servers reboot more quickly these days, and there is a potential risk here. One reader points out:

Boot time is not the only means by which a crashed IP address may be restarted -- for instance, an IP address in a modem pool may be re-assigned within seconds of its last use (or even shorter -- ISDN, for instance). Add to this any number of 'embedded' devices that are quickly restartable, and there are plenty of systems that might be thought to be subject to such a delay on sending new packets.

And another reader says the following

People have effectively wiped out the MSL delay with dynamic IP address assignment, where the addresses are assigned to different clients whenever they are called for -- at periods when the pool is busy, of course, that would mean turnover of addresses within a few seconds.

I'd imagine (but I haven't run an ISP, so I don't know) that this has been done for quite some time -- with firewalls being implemented at more clients, of course, it's anyone's guess as to how long we'll go before we have to re-implement the MSL delay on assigning IP addresses to new dialups, or explain to our users that they'll be responding with RSTs to random machines for their first two or three minutes of activity :-)

p. 253

RFC 2018, a proposed standard, revives the proposal for Selective Acknowledgements, originally floated in RFC 1072. This adds one SYN-only option (to state that the option should be enabled), and one option that can come with any ACK segment. We describe this in our notes for page 312. RFC 2883 makes a further extension to this in the area of duplicate segments. As of August 2001, Sun's Solaris 7 was one of the few commercial operating systems to support selective acknowledgements. By default the support is ``passive'', i.e. it will be returned in the second SYN if the active open SYN from the other end had it enabled. By patching the kernel<sup>49</sup>, it can be made ``active'', i.e. Solaris will enable it on active opens. See also RFC 3517 on selective acknowledgements in particular the observation ``SACK information is advisory and therefore SACKed data MUST NOT be removed from TCP's retransmission buffer until the data is cumulatively acknowledged [RFC2018]''.

p. 254

An option found on many Unix servers is to economise on listeners by having a generic listener, often called inetd, which listens on a variety of ports (TCP and UDP) and forks a specific program to handle any incoming call. The set of ports to listen to and the associated programs is generally listed in a file, often inetd.conf. For machines that are rarely servers, e.g. desktop machines, this can economise on other system resources, even though not on the number of LISTEN entries in the tables reported by netstat.

p. 256

The possibility described here of restricting the local address, has one particular application. As described in III, p. 180 (option 1) some implementations of IP let one bind multiple IP addresses to one link-layer (e.g. Ethernet) address. Each IP address can then correspond to a different www.X.com (or whatever) address, and different HTTP servers can be run, each restricting its local address to the address corresponding to the www.X.com that it is serving.