MTU stuff
Steve Deering <deering@pescadero.stanford.edu> Mon, 11 December 1989 10:52 UTC
Received: from decwrl.dec.com by acetes.pa.dec.com (5.54.5/4.7.34) id AA26902; Mon, 11 Dec 89 02:52:06 PST
Received: by decwrl.dec.com; id AA27026; Mon, 11 Dec 89 02:52:02 -0800
Received: by Pescadero.Stanford.EDU (5.59/25-eef) id AA06695; Mon, 11 Dec 89 02:50:49 PDT
Date: Mon, 11 Dec 1989 01:41:00 -0000
From: Steve Deering <deering@pescadero.stanford.edu>
Subject: MTU stuff
To: mtudwg
Message-Id: <89/12/11
Some more random comments. I'm puzzled. Some of you reject the report-fragmentation approach because it causes fragmentation to occur every once in a while. Instead, you suggest the use of an IP option to discover the MTU in advance. For performance reasons, you realize you don't want to send the option very often. But that means that a downward change in MTU can cause *many* more of the dreaded fragmentations to occur, until you get around to asking for the MTU again. Keith's report-next-N-fragmentations scheme addresses this problem, but requires messy state maintenance and probably degrades performance (matching the state -- dest/TOS/etc. -- and counting up to N). Assuming an IP-layer MTU cache, my scheme causes fragmentation to occur for one RTT every 10 or 15 minutes, only on those paths whose MTU is smaller than you want to send [i.e., less than MIN(MSS,first-hop-MTU)]. Doesn't sound like such a big deal to me. This strategy of "banging your head against a brick wall just to check if the wall is still there" (in Keith's words) is exactly analogous to Van's algorithm for determining the optimum window size, in which an occasional packet loss is tolerated. On the question of whether or not a gateway can tell if it is the last hop for a particular datagram, the semantics of strict source routing make it mandatory that a gateway be able to tell if a destination is directly reachable. If proxy ARP or subnetting implementations are deceiving some gateways, then they are violating the security assumptions behind strict source routing. Furthermore, while it may be true that a gateway may not know the MTU of a neighboring host, the gateway is only required to fragment a datagram to the "natural" MTU of the intervening subnet. That means, if a host advertises an MSS of any value less than or equal to the natural MTU of its connected subnet, then the host's MTU must be at least as big as that MSS. That is: host-MTU must be >= MIN (advertised-MSS, subnet-MTU) e.g., an Ethernet host must not advertise an MSS of 1500 if its MTU is only 576. (Not exactly right, since MTUs include space for the IP header and MSSs don't, but you get the idea. I also am overlookng the issue of subnets with no "natural" MTU, such as HyperChannel, or with more than one "natural" MTU, such as bridged abominations.) Steve
- MTU stuff Steve Deering