rfc2923.txt

RFC 的详细文档！

Network Working Group                                        K. Lahey
Request for Comments: 2923                            dotRocket, Inc.
Category: Informational                                September 2000


                  TCP Problems with Path MTU Discovery

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

Abstract

   This memo catalogs several known Transmission Control Protocol (TCP)
   implementation problems dealing with Path Maximum Transmission Unit
   Discovery (PMTUD), including the long-standing black hole problem,
   stretch acknowlegements (ACKs) due to confusion between Maximum
   Segment Size (MSS) and segment size, and MSS advertisement based on
   PMTU.

1. Introduction

   This memo catalogs several known TCP implementation problems dealing
   with Path MTU Discovery [RFC1191], including the long-standing black
   hole problem, stretch ACKs due to confusion between MSS and segment
   size, and MSS advertisement based on PMTU.  The goal in doing so is
   to improve conditions in the existing Internet by enhancing the
   quality of current TCP/IP implementations.

   While Path MTU Discovery (PMTUD) can be used with any upper-layer
   protocol, it is most commonly used by TCP;  this document does not
   attempt to treat problems encountered by other upper-layer protocols.
   Path MTU Discovery for IPv6 [RFC1981] treats only IPv6-dependent
   issues, but not the TCP issues brought up in this document.

   Each problem is defined as follows:

   Name of Problem
      The name associated with the problem.  In this memo, the name is
      given as a subsection heading.





Lahey                        Informational                      [Page 1]

RFC 2923          TCP Problems with Path MTU Discovery    September 2000


   Classification
      One or more problem categories for which the problem is
      classified:  "congestion control", "performance", "reliability",
      "non-interoperation -- connectivity failure".

   Description
      A definition of the problem, succinct but including necessary
      background material.

   Significance
      A brief summary of the sorts of environments for which the problem
      is significant.

   Implications
      Why the problem is viewed as a problem.

   Relevant RFCs
      The RFCs defining the TCP specification with which the problem
      conflicts.  These RFCs often qualify behavior using terms such as
      MUST, SHOULD, MAY, and others written capitalized.  See RFC 2119
      for the exact interpretation of these terms.

   Trace file demonstrating the problem
      One or more ASCII trace files demonstrating the problem, if
      applicable.

   Trace file demonstrating correct behavior
      One or more examples of how correct behavior appears in a trace,
      if applicable.

   References
      References that further discuss the problem.

   How to detect
      How to test an implementation to see if it exhibits the problem.
      This discussion may include difficulties and subtleties associated
      with causing the problem to manifest itself, and with interpreting
      traces to detect the presence of the problem (if applicable).

   How to fix
      For known causes of the problem, how to correct the
      implementation.









Lahey                        Informational                      [Page 2]

RFC 2923          TCP Problems with Path MTU Discovery    September 2000


2. Known implementation problems

2.1.

   Name of Problem
      Black Hole Detection

   Classification
      Non-interoperation -- connectivity failure

   Description
      A host performs Path MTU Discovery by sending out as large a
      packet as possible, with the Don't Fragment (DF) bit set in the IP
      header.  If the packet is too large for a router to forward on to
      a particular link, the router must send an ICMP Destination
      Unreachable -- Fragmentation Needed message to the source address.
      The host then adjusts the packet size based on the ICMP message.

      As was pointed out in [RFC1435], routers don't always do this
      correctly -- many routers fail to send the ICMP messages, for a
      variety of reasons ranging from kernel bugs to configuration
      problems.  Firewalls are often misconfigured to suppress all ICMP
      messages.  IPsec [RFC2401] and IP-in-IP [RFC2003] tunnels
      shouldn't cause these sorts of problems, if the implementations
      follow the advice in the appropriate documents.

      PMTUD, as documented in [RFC1191], fails when the appropriate ICMP
      messages are not received by the originating host.  The upper-
      layer protocol continues to try to send large packets and, without
      the ICMP messages, never discovers that it needs to reduce the
      size of those packets.  Its packets are disappearing into a PMTUD
      black hole.

   Significance
      When PMTUD fails due to the lack of ICMP messages, TCP will also
      completely fail under some conditions.

   Implications
      This failure is especially difficult to debug, as pings and some
      interactive TCP connections to the destination host work.  Bulk
      transfers fail with the first large packet and the connection
      eventually times out.

      These situations can almost always be blamed on a misconfiguration
      within the network, which should be corrected.  However it seems
      inappropriate for some TCP implementations to suffer





Lahey                        Informational                      [Page 3]

RFC 2923          TCP Problems with Path MTU Discovery    September 2000


      interoperability failures over paths which do not affect other TCP
      implementations (i.e. those without PMTUD).  This creates a market
      disincentive for deploying TCP implementation with PMTUD enabled.

   Relevant RFCs
      RFC 1191 describes Path MTU Discovery.  RFC 1435 provides an early
      description of these sorts of problems.

   Trace file demonstrating the problem
      Made using tcpdump [Jacobson89] recording at an intermediate host.

      20:12:11.951321 A > B: S 1748427200:1748427200(0)
           win 49152 <mss 1460>
      20:12:11.951829 B > A: S 1001927984:1001927984(0)
           ack 1748427201 win 16384 <mss 65240>
      20:12:11.955230 A > B: . ack 1 win 49152 (DF)
      20:12:11.959099 A > B: . 1:1461(1460) ack 1 win 49152 (DF)
      20:12:13.139074 A > B: . 1:1461(1460) ack 1 win 49152 (DF)
      20:12:16.188685 A > B: . 1:1461(1460) ack 1 win 49152 (DF)
      20:12:22.290483 A > B: . 1:1461(1460) ack 1 win 49152 (DF)
      20:12:34.491856 A > B: . 1:1461(1460) ack 1 win 49152 (DF)
      20:12:58.896405 A > B: . 1:1461(1460) ack 1 win 49152 (DF)
      20:13:47.703184 A > B: . 1:1461(1460) ack 1 win 49152 (DF)
      20:14:52.780640 A > B: . 1:1461(1460) ack 1 win 49152 (DF)
      20:15:57.856037 A > B: . 1:1461(1460) ack 1 win 49152 (DF)
      20:17:02.932431 A > B: . 1:1461(1460) ack 1 win 49152 (DF)
      20:18:08.009337 A > B: . 1:1461(1460) ack 1 win 49152 (DF)
      20:19:13.090521 A > B: . 1:1461(1460) ack 1 win 49152 (DF)
      20:20:18.168066 A > B: . 1:1461(1460) ack 1 win 49152 (DF)
      20:21:23.242761 A > B: R 1461:1461(0) ack 1 win 49152 (DF)

      The short SYN packet has no trouble traversing the network, due to
      its small size.  Similarly, ICMP echo packets used to diagnose
      connectivity problems will succeed.

      Large data packets fail to traverse the network.  Eventually the
      connection times out.  This can be especially confusing when the
      application starts out with a very small write, which succeeds,
      following up with many large writes, which then fail.

   Trace file demonstrating correct behavior

      Made using tcpdump recording at an intermediate host.

      16:48:42.659115 A > B: S 271394446:271394446(0)
           win 8192 <mss 1460> (DF)
      16:48:42.672279 B > A: S 2837734676:2837734676(0)
           ack 271394447 win 16384 <mss 65240>



Lahey                        Informational                      [Page 4]

RFC 2923          TCP Problems with Path MTU Discovery    September 2000


      16:48:42.676890 A > B: . ack 1 win 8760 (DF)
      16:48:42.870574 A > B: . 1:1461(1460) ack 1 win 8760 (DF)
      16:48:42.871799 A > B: . 1461:2921(1460) ack 1 win 8760 (DF)
      16:48:45.786814 A > B: . 1:1461(1460) ack 1 win 8760 (DF)
      16:48:51.794676 A > B: . 1:1461(1460) ack 1 win 8760 (DF)
      16:49:03.808912 A > B: . 1:537(536) ack 1 win 8760
      16:49:04.016476 B > A: . ack 537 win 16384
      16:49:04.021245 A > B: . 537:1073(536) ack 1 win 8760
      16:49:04.021697 A > B: . 1073:1609(536) ack 1 win 8760
      16:49:04.120694 B > A: . ack 1609 win 16384
      16:49:04.126142 A > B: . 1609:2145(536) ack 1 win 8760

      In this case, the sender sees four packets fail to traverse the
      network (using a two-packet initial send window) and turns off
      PMTUD.  All subsequent packets have the DF flag turned off, and
      the size set to the default value of 536 [RFC1122].

   References
      This problem has been discussed extensively on the tcp-impl
      mailing list;  the name "black hole" has been in use for many
      years.

   How to detect
      This shows up as a TCP connection which hangs (fails to make
      progress) until closed by timeout (this often manifests itself as
      a connection that connects and starts to transfer, then eventually
      terminates after 15 minutes with zero bytes transfered).  This is
      particularly annoying with an application like ftp, which will
      work perfectly while it uses small packets for control
      information, and then fail on bulk transfers.

      A series of ICMP echo packets will show that the two end hosts are
      still capable of passing packets,  a series of MTU-sized ICMP echo
      packets will show some fragmentation, and a series of MTU-sized
      ICMP echo packets with DF set will fail.  This can be confusing
      for network engineers trying to diagnose the problem.

      There are several traceroute implementations that do PMTUD, and
      can demonstrate the problem.

   How to fix
      TCP should notice that the connection is timing out.  After
      several timeouts, TCP should attempt to send smaller packets,
      perhaps turning off the DF flag for each packet.  If this
      succeeds, it should continue to turn off PMTUD for the connection
      for some reasonable period of time, after which it should probe
      again to try to determine if the path has changed.




Lahey                        Informational                      [Page 5]