CAUSE
Windows NT 3.5 and 3.51 TCP/IP uses PMTU (Path Maximum Transfer Unit)
discovery to determine the optimum TCP segment size that can be used
for data transfers on a path between two computers. PMTU discovery is
described in RFC1191. Following is an excerpt from that RFC:
When a router is unable to forward a datagram because it exceeds the
MTU of the next-hop network and its Don't Fragment bit is set, the
router is required to return an ICMP Destination Unreachable message
to the source of the datagram, with the Code indicating
"fragmentation needed and DF set". To support the Path MTU Discovery
technique specified in this memo, the router MUST include the MTU of
that next-hop network in the low-order 16 bits of the ICMP header
field that is labeled "unused" in the ICMP specification [7]. The
high-order 16 bits remain unused, and MUST be set to zero. Thus, the
message has the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 3 | Code = 4 | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| unused = 0 | Next-Hop MTU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Internet Header + 64 bits of Original Datagram Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
When a computer running Windows NT 3.5 or 3.51 is used as a router, it does
return the ICMP Destination Unreachable message; however it does not
include the MTU of the next-hop network. This forces the sending computer
to retransmit the data, guessing at the next-hop MTU. Because it can take
several guesses to determine the correct value, a small delay can occur.
The following trace, captured by Microsoft Network Monitor, illustrates
this behavior:
# Source Dest Prot Description
1 server client TCP ....S., len: 4, seq:1286279, ack:0, win: 8192,
2 client server TCP .A..S., len: 4, seq:659688, ack:1286280, win: 8760
3 server client TCP .A...., len: 0, seq:1286280, ack:659689, win: 8760
4 client server FTP Data Transfer To Server, Port = 1028, size 1460
5 router client ICMP Destination Unreachable, Destination: 199.199.40.14
6 client server TCP .A...., len: 0, seq:643477, ack:1270209, win: 8558
7 client server FTP Data Transfer To Server, Port = 1028, size 966
8 router client ICMP Destination Unreachable, Destination: 199.199.40.14
9 client server FTP Data Transfer To Server, Port = 1028, size 468
10 server client TCP .A...., len: 0, seq:1286280, ack:660157, win: 8292
11 client server FTP Data Transfer To Server, Port = 1028, size 468
12 client server FTP Data Transfer To Server, Port = 1028, size 468
13 server client TCP .A...., len: 0, seq:1286280, ack:661093, win: 8760
14 client server FTP Data Transfer To Server, Port = 1028, size 468
15 client server FTP Data Transfer To Server, Port = 1028, size 468
- The first three frames show the 3-way handshake to set up the
connection.
- The fourth frame shows an attempt to send a 1460 byte TCP segment over
the path (through a Windows NT 3.51 router).
- The fifth frame shows the Windows NT 3.51 router returning an ICMP
error, destination unreachable (fragmentation needed, but DF bit set)
- The seventh frame shows the client trying a 966 byte segment. This is
the next "likely" MSS (Maximum Segment Size) down from 1460.
- The eighth frame is another ICMP destination unreachable message.
- The ninth frame shows the client trying a 468 byte segment. This
succeeds, and the transfer continues using that value.