home *** CD-ROM | disk | FTP | other *** search
/ Unix System Administration Handbook 1997 October / usah_oct97.iso / rfc / 800s / rfc879.txt < prev    next >
Text File  |  1992-09-22  |  22KB  |  639 lines
  1.  
  2.  
  3. Network Working Group                                          J. Postel
  4. Request for Comments: 879                                            ISI
  5.                                                            November 1983
  6.  
  7.  
  8.  
  9.                       The TCP Maximum Segment Size
  10.                            and Related Topics
  11.  
  12. This memo discusses the TCP Maximum Segment Size Option and related
  13. topics.  The purposes is to clarify some aspects of TCP and its
  14. interaction with IP.  This memo is a clarification to the TCP
  15. specification, and contains information that may be considered as
  16. "advice to implementers".
  17.  
  18. 1.  Introduction
  19.  
  20.    This memo discusses the TCP Maximum Segment Size and its relation to
  21.    the IP Maximum Datagram Size.  TCP is specified in reference [1].  IP
  22.    is specified in references [2,3].
  23.  
  24.    This discussion is necessary because the current specification of
  25.    this TCP option is ambiguous.
  26.  
  27.    Much of the difficulty with understanding these sizes and their
  28.    relationship has been due to the variable size of the IP and TCP
  29.    headers.
  30.  
  31.    There have been some assumptions made about using other than the
  32.    default size for datagrams with some unfortunate results.
  33.  
  34.       HOSTS MUST NOT SEND DATAGRAMS LARGER THAN 576 OCTETS UNLESS THEY
  35.       HAVE SPECIFIC KNOWLEDGE THAT THE DESTINATION HOST IS PREPARED TO
  36.       ACCEPT LARGER DATAGRAMS.
  37.  
  38.          This is a long established rule.
  39.  
  40.    To resolve the ambiguity in the TCP Maximum Segment Size option
  41.    definition the following rule is established:
  42.  
  43.       THE TCP MAXIMUM SEGMENT SIZE IS THE IP MAXIMUM DATAGRAM SIZE MINUS
  44.       FORTY.
  45.  
  46.          The default IP Maximum Datagram Size is 576.
  47.          The default TCP Maximum Segment Size is 536.
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57. Postel                                                          [Page 1]
  58.  
  59.  
  60.  
  61. RFC 879                                                    November 1983
  62. TCP Maximum Segment Size                                                
  63.  
  64.  
  65. 2.  The IP Maximum Datagram Size
  66.  
  67.    Hosts are not required to reassemble infinitely large IP datagrams.
  68.    The maximum size datagram that all hosts are required to accept or
  69.    reassemble from fragments is 576 octets.  The maximum size reassembly
  70.    buffer every host must have is 576 octets.  Hosts are allowed to
  71.    accept larger datagrams and assemble fragments into larger datagrams,
  72.    hosts may have buffers as large as they please.
  73.  
  74.    Hosts must not send datagrams larger than 576 octets unless they have
  75.    specific knowledge that the destination host is prepared to accept
  76.    larger datagrams.
  77.  
  78. 3.  The TCP Maximum Segment Size Option
  79.  
  80.    TCP provides an option that may be used at the time a connection is
  81.    established (only) to indicate the maximum size TCP segment that can
  82.    be accepted on that connection.  This Maximum Segment Size (MSS)
  83.    announcement (often mistakenly called a negotiation) is sent from the
  84.    data receiver to the data sender and says "I can accept TCP segments
  85.    up to size X". The size (X) may be larger or smaller than the
  86.    default.  The MSS can be used completely independently in each
  87.    direction of data flow.  The result may be quite different maximum
  88.    sizes in the two directions.
  89.  
  90.    The MSS counts only data octets in the segment, it does not count the
  91.    TCP header or the IP header.
  92.  
  93.    A footnote:  The MSS value counts only data octets, thus it does not
  94.    count the TCP SYN and FIN control bits even though SYN and FIN do
  95.    consume TCP sequence numbers.
  96.  
  97. 4.  The Relationship of TCP Segments and IP Datagrams
  98.  
  99.    TCP segment are transmitted as the data in IP datagrams.  The
  100.    correspondence between TCP segments and IP datagrams must be one to
  101.    one.  This is because TCP expects to find exactly one complete TCP
  102.    segment in each block of data turned over to it by IP, and IP must
  103.    turn over a block of data for each datagram received (or completely
  104.    reassembled).
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114.  
  115. Postel                                                          [Page 2]
  116.  
  117.  
  118.  
  119. RFC 879                                                    November 1983
  120. TCP Maximum Segment Size                                                
  121.  
  122.  
  123. 5.  Layering and Modularity
  124.  
  125.    TCP is an end to end reliable data stream protocol with error
  126.    control, flow control, etc.  TCP remembers many things about the
  127.    state of a connection.
  128.  
  129.    IP is a one shot datagram protocol.  IP has no memory of the
  130.    datagrams transmitted.  It is not appropriate for IP to keep any
  131.    information about the maximum datagram size a particular destination
  132.    host might be capable of accepting.
  133.  
  134.    TCP and IP are distinct layers in the protocol architecture, and are
  135.    often implemented in distinct program modules.
  136.  
  137.    Some people seem to think that there must be no communication between
  138.    protocol layers or program modules.  There must be communication
  139.    between layers and modules, but it should be carefully specified and
  140.    controlled.  One problem in understanding the correct view of
  141.    communication between protocol layers or program modules in general,
  142.    or between TCP and IP in particular is that the documents on
  143.    protocols are not very clear about it.  This is often because the
  144.    documents are about the protocol exchanges between machines, not the
  145.    program architecture within a machine, and the desire to allow many
  146.    program architectures with different organization of tasks into
  147.    modules.
  148.  
  149. 6.  IP Information Requirements
  150.  
  151.    There is no general requirement that IP keep information on a per
  152.    host basis.
  153.  
  154.    IP must make a decision about which directly attached network address
  155.    to send each datagram to.  This is simply mapping an IP address into
  156.    a directly attached network address.
  157.  
  158.    There are two cases to consider:  the destination is on the same
  159.    network, and the destination is on a different network.
  160.  
  161.       Same Network
  162.  
  163.          For some networks the the directly attached network address can
  164.          be computed from the IP address for destination hosts on the
  165.          directly attached network.
  166.  
  167.          For other networks the mapping must be done by table look up
  168.          (however the table is initialized and maintained, for
  169.          example, [4]).
  170.  
  171.  
  172.  
  173. Postel                                                          [Page 3]
  174.  
  175.  
  176.  
  177. RFC 879                                                    November 1983
  178. TCP Maximum Segment Size                                                
  179.  
  180.  
  181.       Different Network
  182.  
  183.          The IP address must be mapped to the directly attached network
  184.          address of a gateway.  For networks with one gateway to the
  185.          rest of the Internet the host need only determine and remember
  186.          the gateway address and use it for sending all datagrams to
  187.          other networks.
  188.  
  189.          For networks with multiple gateways to the rest of the
  190.          Internet, the host must decide which gateway to use for each
  191.          datagram sent.  It need only check the destination network of
  192.          the IP address and keep information on which gateway to use for
  193.          each network.
  194.  
  195.    The IP does, in some cases, keep per host routing information for
  196.    other hosts on the directly attached network.  The IP does, in some
  197.    cases, keep per network routing information.
  198.  
  199.    A Special Case
  200.  
  201.       There are two ICMP messages that convey information about
  202.       particular hosts.  These are subtypes of the Destination
  203.       Unreachable and the Redirect ICMP messages.  These messages are
  204.       expected only in very unusual circumstances.  To make effective
  205.       use of these messages the receiving host would have to keep
  206.       information about the specific hosts reported on.  Because these
  207.       messages are quite rare it is strongly recommended that this be
  208.       done through an exception mechanism rather than having the IP keep
  209.       per host tables for all hosts.
  210.  
  211. 7.  The Relationship between IP Datagram and TCP Segment Sizes
  212.  
  213.    The relationship between the value of the maximum IP datagram size
  214.    and the maximum TCP segment size is obscure.  The problem is that
  215.    both the IP header and the TCP header may vary in length.  The TCP
  216.    Maximum Segment Size option (MSS) is defined to specify the maximum
  217.    number of data octets in a TCP segment exclusive of TCP (or IP)
  218.    header.
  219.  
  220.    To notify the data sender of the largest TCP segment it is possible
  221.    to receive the calculation of the MSS value to send is:
  222.  
  223.       MSS = MTU - sizeof(TCPHDR) - sizeof(IPHDR)
  224.  
  225.    On receipt of the MSS option the calculation of the size of segment
  226.    that can be sent is:
  227.  
  228.       SndMaxSegSiz = MIN((MTU - sizeof(TCPHDR) - sizeof(IPHDR)), MSS)
  229.  
  230.  
  231. Postel                                                          [Page 4]
  232.  
  233.  
  234.  
  235. RFC 879                                                    November 1983
  236. TCP Maximum Segment Size                                                
  237.  
  238.  
  239.    where MSS is the value in the option, and MTU is the Maximum
  240.    Transmission Unit (or the maximum packet size) allowed on the
  241.    directly attached network.
  242.  
  243.    This begs the question, though.  What value should be used for the
  244.    "sizeof(TCPHDR)" and for the "sizeof(IPHDR)"?
  245.  
  246.    There are three reasonable positions to take: the conservative, the
  247.    moderate, and the liberal.
  248.  
  249.    The conservative or pessimistic position assumes the worst -- that
  250.    both the IP header and the TCP header are maximum size, that is, 60
  251.    octets each.
  252.  
  253.       MSS = MTU - 60 - 60 = MTU - 120
  254.  
  255.       If MTU is 576 then MSS = 456
  256.  
  257.    The moderate position assumes the that the IP is maximum size (60
  258.    octets) and the TCP header is minimum size (20 octets), because there
  259.    are no TCP header options currently defined that would normally be
  260.    sent at the same time as data segments.
  261.  
  262.       MSS = MTU - 60 - 20 = MTU - 80
  263.  
  264.       If MTU is 576 then MSS = 496
  265.  
  266.    The liberal or optimistic position assumes the best -- that both the
  267.    IP header and the TCP header are minimum size, that is, 20 octets
  268.    each.
  269.  
  270.       MSS = MTU - 20 - 20 = MTU - 40
  271.  
  272.       If MTU is 576 then MSS = 536
  273.  
  274.       If nothing is said about MSS, the data sender may cram as much as
  275.       possible into a 576 octet datagram, and if the datagram has
  276.       minimum headers (which is most likely), the result will be 536
  277.       data octets in the TCP segment.  The rule relating MSS to the
  278.       maximum datagram size ought to be consistent with this.
  279.  
  280.    A practical point is raised in favor of the liberal position too.
  281.    Since the use of minimum IP and TCP headers is very likely in the
  282.    very large percentage of cases, it seems wasteful to limit the TCP
  283.    segment data to so much less than could be transmitted at once,
  284.    especially since it is less that 512 octets.
  285.  
  286.  
  287.  
  288.  
  289. Postel                                                          [Page 5]
  290.  
  291.  
  292.  
  293. RFC 879                                                    November 1983
  294. TCP Maximum Segment Size                                                
  295.  
  296.  
  297.       For comparison:  536/576 is 93% data, 496/576 is 86% data, 456/576
  298.       is 79% data.
  299.  
  300. 8.  Maximum Packet Size
  301.  
  302.    Each network has some maximum packet size, or maximum transmission
  303.    unit (MTU).  Ultimately there is some limit imposed by the
  304.    technology, but often the limit is an engineering choice or even an
  305.    administrative choice.  Different installations of the same network
  306.    product do not have to use the same maximum packet size.  Even within
  307.    one installation not all host must use the same packet size (this way
  308.    lies madness, though).
  309.  
  310.    Some IP implementers have assumed that all hosts on the directly
  311.    attached network will be the same or at least run the same
  312.    implementation.  This is a dangerous assumption.  It has often
  313.    developed that after a small homogeneous set of host have become
  314.    operational additional hosts of different types are introduced into
  315.    the environment.  And it has often developed that it is desired to
  316.    use a copy of the implementation in a different inhomogeneous
  317.    environment.
  318.  
  319.    Designers of gateways should be prepared for the fact that successful
  320.    gateways will be copied and used in other situation and
  321.    installations.  Gateways must be prepared to accept datagrams as
  322.    large as can be sent in the maximum packets of the directly attached
  323.    networks.  Gateway implementations should be easily configured for
  324.    installation in different circumstances.
  325.  
  326.    A footnote:  The MTUs of some popular networks (note that the actual
  327.    limit in some installations may be set lower by administrative
  328.    policy):
  329.  
  330.       ARPANET, MILNET = 1007
  331.       Ethernet (10Mb) = 1500
  332.       Proteon PRONET  = 2046
  333.  
  334. 9.  Source Fragmentation
  335.  
  336.    A source host would not normally create datagram fragments.  Under
  337.    normal circumstances datagram fragments only arise when a gateway
  338.    must send a datagram into a network with a smaller maximum packet
  339.    size than the datagram.  In this case the gateway must fragment the
  340.    datagram (unless it is marked "don't fragment" in which case it is
  341.    discarded, with the option of sending an ICMP message to the source
  342.    reporting the problem).
  343.  
  344.    It might be desirable for the source host to send datagram fragments
  345.  
  346.  
  347. Postel                                                          [Page 6]
  348.  
  349.  
  350.  
  351. RFC 879                                                    November 1983
  352. TCP Maximum Segment Size                                                
  353.  
  354.  
  355.    if the maximum segment size (default or negotiated) allowed by the
  356.    data receiver were larger than the maximum packet size allowed by the
  357.    directly attached network.  However, such datagram fragments must not
  358.    combine to a size larger than allowed by the destination host.
  359.  
  360.       For example, if the receiving TCP announced that it would accept
  361.       segments up to 5000 octets (in cooperation with the receiving IP)
  362.       then the sending TCP could give such a large segment to the
  363.       sending IP provided the sending IP would send it in datagram
  364.       fragments that fit in the packets of the directly attached
  365.       network.
  366.  
  367.    There are some conditions where source host fragmentation would be
  368.    necessary.
  369.  
  370.       If the host is attached to a network with a small packet size (for
  371.       example 256 octets), and it supports an application defined to
  372.       send fixed sized messages larger than that packet size (for
  373.       example TFTP [5]).
  374.  
  375.       If the host receives ICMP Echo messages with data it is required
  376.       to send an ICMP Echo-Reply message with the same data.  If the
  377.       amount of data in the Echo were larger than the packet size of the
  378.       directly attached network the following steps might be required:
  379.       (1) receive the fragments, (2) reassemble the datagram, (3)
  380.       interpret the Echo, (4) create an Echo-Reply, (5) fragment it, and
  381.       (6) send the fragments.
  382.  
  383. 10. Gateway Fragmentation
  384.  
  385.    Gateways must be prepared to do fragmentation.  It is not an optional
  386.    feature for a gateway.
  387.  
  388.    Gateways have no information about the size of datagrams destination
  389.    hosts are prepared to accept.  It would be inappropriate for gateways
  390.    to attempt to keep such information.
  391.  
  392.    Gateways must be prepared to accept the largest datagrams that are
  393.    allowed on each of the directly attached networks, even if it is
  394.    larger than 576 octets.
  395.  
  396.    Gateways must be prepared to fragment datagrams to fit into the
  397.    packets of the next network, even if it smaller than 576 octets.
  398.  
  399.    If a source host thought to take advantage of the local network's
  400.    ability to carry larger datagrams but doesn't have the slightest idea
  401.    if the destination host can accept larger than default datagrams and
  402.    expects the gateway to fragment the datagram into default size
  403.  
  404.  
  405. Postel                                                          [Page 7]
  406.  
  407.  
  408.  
  409. RFC 879                                                    November 1983
  410. TCP Maximum Segment Size                                                
  411.  
  412.  
  413.    fragments, then the source host is misguided.  If indeed, the
  414.    destination host can't accept larger than default datagrams, it
  415.    probably can't reassemble them either. If the gateway either passes
  416.    on the large datagram whole or fragments into default size fragments
  417.    the destination will not accept it.  Thus, this mode of behavior by
  418.    source hosts must be outlawed.
  419.  
  420.    A larger than default datagram can only arrive at a gateway because
  421.    the source host knows that the destination host can handle such large
  422.    datagrams (probably because the destination host announced it to the
  423.    source host in an TCP MSS option).  Thus, the gateway should pass on
  424.    this large datagram in one piece or in the largest fragments that fit
  425.    into the next network.
  426.  
  427.    An interesting footnote is that even though the gateways may know
  428.    about know the 576 rule, it is irrelevant to them.
  429.  
  430. 11. Inter-Layer Communication
  431.  
  432.    The Network Driver (ND) or interface should know the Maximum
  433.    Transmission Unit (MTU) of the directly attached network.
  434.  
  435.    The IP should ask the Network Driver for the Maximum Transmission
  436.    Unit.
  437.  
  438.    The TCP should ask the IP for the Maximum Datagram Data Size (MDDS).
  439.    This is the MTU minus the IP header length (MDDS = MTU - IPHdrLen).
  440.  
  441.    When opening a connection TCP can send an MSS option with the value
  442.    equal MDDS - TCPHdrLen.
  443.  
  444.    TCP should determine the Maximum Segment Data Size (MSDS) from either
  445.    the default or the received value of the MSS option.
  446.  
  447.    TCP should determine if source fragmentation is possible (by asking
  448.    the IP) and desirable.
  449.  
  450.       If so TCP may hand to IP segments (including the TCP header) up to
  451.       MSDS + TCPHdrLen.
  452.  
  453.       If not TCP may hand to IP segments (including the TCP header) up
  454.       to the lesser of (MSDS + TCPHdrLen) and MDDS.
  455.  
  456.    IP checks the length of data passed to it by TCP.  If the length is
  457.    less than or equal MDDS, IP attached the IP header and hands it to
  458.    the ND.  Otherwise the IP must do source fragmentation.
  459.  
  460.  
  461.  
  462.  
  463. Postel                                                          [Page 8]
  464.  
  465.  
  466.  
  467. RFC 879                                                    November 1983
  468. TCP Maximum Segment Size                                                
  469.  
  470.  
  471. 12. What is the Default MSS ?
  472.  
  473.    Another way of asking this question is "What transmitted value for
  474.    MSS has exactly the same effect of not transmitting the option at
  475.    all?".
  476.  
  477.    In terms of the previous section:
  478.  
  479.       The default assumption is that the Maximum Transmission Unit is
  480.       576 octets.
  481.  
  482.          MTU = 576
  483.  
  484.       The Maximum Datagram Data Size (MDDS) is the MTU minus the IP
  485.       header length.
  486.  
  487.          MDDS = MTU - IPHdrLen = 576 - 20 = 556
  488.  
  489.       When opening a connection TCP can send an MSS option with the
  490.       value equal MDDS - TCPHdrLen.
  491.  
  492.          MSS = MDDS - TCPHdrLen = 556 - 20 = 536
  493.  
  494.       TCP should determine the Maximum Segment Data Size (MSDS) from
  495.       either the default or the received value of the MSS option.
  496.  
  497.          Default MSS = 536, then MSDS = 536
  498.  
  499.       TCP should determine if source fragmentation is possible and
  500.       desirable.
  501.  
  502.          If so TCP may hand to IP segments (including the TCP header) up
  503.          to MSDS + TCPHdrLen (536 + 20 = 556).
  504.  
  505.          If not TCP may hand to IP segments (including the TCP header)
  506.          up to the lesser of (MSDS + TCPHdrLen (536 + 20 = 556)) and
  507.          MDDS (556).
  508.  
  509.  
  510.  
  511.  
  512.  
  513.  
  514.  
  515.  
  516.  
  517.  
  518.  
  519.  
  520.  
  521. Postel                                                          [Page 9]
  522.  
  523.  
  524.  
  525. RFC 879                                                    November 1983
  526. TCP Maximum Segment Size                                                
  527.  
  528.  
  529. 13. The Truth
  530.  
  531.    The rule relating the maximum IP datagram size and the maximum TCP
  532.    segment size is:
  533.  
  534.       TCP Maximum Segment Size = IP Maximum Datagram Size - 40
  535.  
  536.    The rule must match the default case.
  537.  
  538.       If the TCP Maximum Segment Size option is not transmitted then the
  539.       data sender is allowed to send IP datagrams of maximum size (576)
  540.       with a minimum IP header (20) and a minimum TCP header (20) and
  541.       thereby be able to stuff 536 octets of data into each TCP segment.
  542.  
  543.    The definition of the MSS option can be stated:
  544.  
  545.       The maximum number of data octets that may be received by the
  546.       sender of this TCP option in TCP segments with no TCP header
  547.       options transmitted in IP datagrams with no IP header options.
  548.  
  549. 14. The Consequences
  550.  
  551.    When TCP is used in a situation when either the IP or TCP headers are
  552.    not minimum and yet the maximum IP datagram that can be received
  553.    remains 576 octets then the TCP Maximum Segment Size option must be
  554.    used to reduce the limit on data octets allowed in a TCP segment.
  555.  
  556.       For example, if the IP Security option (11 octets) were in use and
  557.       the IP maximum datagram size remained at 576 octets, then the TCP
  558.       should send the MSS with a value of 525 (536-11).
  559.  
  560.  
  561.  
  562.  
  563.  
  564.  
  565.  
  566.  
  567.  
  568.  
  569.  
  570.  
  571.  
  572.  
  573.  
  574.  
  575.  
  576.  
  577.  
  578.  
  579. Postel                                                         [Page 10]
  580.  
  581.  
  582.  
  583. RFC 879                                                    November 1983
  584. TCP Maximum Segment Size                                                
  585.  
  586.  
  587. 15. References
  588.  
  589.    [1]  Postel, J., ed., "Transmission Control Protocol - DARPA Internet
  590.         Program Protocol Specification", RFC 793, USC/Information
  591.         Sciences Institute, September 1981.
  592.  
  593.    [2]  Postel, J., ed., "Internet Protocol - DARPA Internet Program
  594.         Protocol Specification", RFC 791, USC/Information Sciences
  595.         Institute, September 1981.
  596.  
  597.    [3]  Postel, J., "Internet Control Message Protocol - DARPA Internet
  598.         Program Protocol Specification", RFC 792, USC/Information
  599.         Sciences Institute, September 1981.
  600.  
  601.    [4]  Plummer, D., "An Ethernet Address Resolution Protocol or
  602.         Converting Network Protocol Addresses to 48-bit Ethernet
  603.         Addresses for Transmission on Ethernet Hardware", RFC 826,
  604.         MIT/LCS, November 1982.
  605.  
  606.    [5]  Sollins, K., "The TFTP Protocol (Revision 2)", RFC 783, MIT/LCS,
  607.         June 1981.
  608.  
  609.  
  610.  
  611.  
  612.  
  613.  
  614.  
  615.  
  616.  
  617.  
  618.  
  619.  
  620.  
  621.  
  622.  
  623.  
  624.  
  625.  
  626.  
  627.  
  628.  
  629.  
  630.  
  631.  
  632.  
  633.  
  634.  
  635.  
  636.  
  637. Postel                                                         [Page 11]
  638.  
  639.