24.02. Ceļa MTU atrašana

02.09.nodaļā aprakstījām ceļa MTU jēdzienu. Tas ir minimālais no visu to tīklu MTU, kuri veido ceļu starp divām mītnēm. Ceļa MTU atrašanai ir jāuzstāda "nefragmentēt" ("don't fragment", DF) bits IP sākumposmā, lai noskaidrotu, vai kādam maršrutētājam uz pašreizējā ceļa vajag fragmentēt tās IP datagrammas, kuras mēs sūtām. 11.06.nodaļā mēs parādījām ICMP nesasniedzamības ziņojumu, ko atgriež maršrutētājs, kuram lūdz pārsūtīt IP datagrammu, kurai uzstādīts DF bits situācijā, kad MTU ir mazāks nekā datagrammas izmērs. 11.07.nodaļā parādījām versiju traceroute programmai, kura izmantoja šo mehānismu, lai noteiktu ceļa MTU līdz galamērķim. 11.08.nodaļā mēs redzējām, kā UDP apstrādāja ceļa MTU atrašanu. Šajā nodaļā noskaidrosim, kā šo mehānismu izmanto TCP, kā tas norādīts RFC 1191 [Mogul and Deering 1990].

No daudzajām sistēmām, ko izmanto šajā grāmatā (sk. Priekšvārdu) vienīgi Solaris 2.x atbalsta ceļa MTU atrašanu. 

TCP's path MTU discovery operates as follows. When a connection is established, TCP uses the minimum of the MTU of the outgoing interface, or the MSS announced by the other end, as the starting segment size. Path MTU discovery does not allow TCP to exceed the MSS announced by the other end. If the other end does not specify an MSS, it defaults to 536. It is also possible for an implementation to save path MTU information on a per-route basis, as we mentioned in Section 21.9.

Once the initial segment size is chosen, all IP datagrams sent by TCP on that connection have the DF bit set. If an intermediate router needs to fragment a datagram that has the DF bit set, it discards the datagram and generates the ICMP "can't fragment" error we described in Section 11.6.

If this ICMP error is received, TCP decreases the segment size and retransmits. If the router generated the newer form of this ICMP error, the segment size can be set to the next-hop MTU minus the sizes of the IP and TCP headers. If the older ICMP error is returned, the probable value of the next smallest MTU (Figure 2.5) must be tried. When a retransmission caused by this ICMP error occurs, the congestion window should not change, but slow start should be initiated.

Since routes can change dynamically, when some time has passed since the last decrease of the path MTU, a larger value (up to the minimum of the MSS announced by the other end, or the outgoing interface MTU) can be tried. RFC 1191 recommends this time interval be about 10 minutes. (We saw in Section 11.8 that Solaris 2.2 uses a 30-sec-ond timer for this.)

Given the normal default MSS of 536 for nonlocal destinations, path MTU discovery avoids fragmentation across intermediate links with an MTU of less than 576 (which is rare). It can also avoid fragmentation on local destinations when an intermediate link (e.g., an Ethernet) has a smaller MTU than the end-point networks (e.g., a token ring). But for path MTU discovery to be more useful, and take advantage of wide area networks with MTUs greater than 576, implementations must stop using a default MSS of 536 bytes for nonlocal destinations. A better choice for the MSS is the MTU of the outgoing interface (minus the size of the IP and TCP headers, of course). (In Appendix E we'll see that most implementations allow the system administrator to change this default MSS value.)