home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_q_t / draft-ietf-tcpsat-stand-mech-00.txt < prev    next >
Text File  |  1997-10-03  |  30KB  |  649 lines
  1.  
  2. Internet Engineering Task Force                              Mark Allman
  3. INTERNET DRAFT                              NASA Lewis/Sterling Software
  4. File: draft-ietf-tcpsat-stand-mech-00.txt                     Dan Glover
  5.                                                               NASA Lewis
  6.                                                          October 2, 1997
  7.                                                   Expires: April 2, 1998
  8.     
  9.     
  10.                  Enhancing TCP Over Satellite Channels
  11.                        using Standard Mechanisms
  12.     
  13.  
  14. Status of this Memo
  15.                                     
  16.     This document is an Internet-Draft.  Internet-Drafts are working
  17.     documents of the Internet Engineering Task Force (IETF), its areas,
  18.     and its working groups.  Note that other groups may also distribute
  19.     working documents as Internet-Drafts.
  20.  
  21.     Internet-Drafts are draft documents valid for a maximum of six
  22.     months and may be updated, replaced, or obsoleted by other documents
  23.     at any time.  It is inappropriate to use Internet-Drafts as
  24.     reference material or to cite them other than as ``work in
  25.     progress.''
  26.  
  27.     To learn the current status of any Internet-Draft, please check the
  28.     ``1id-abstracts.txt'' listing contained in the Internet- Drafts
  29.     Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
  30.     munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
  31.     ftp.isi.edu (US West Coast).
  32.     
  33. NOTE
  34.  
  35.     This draft is not to be taken as a complete work.  In the future
  36.     this draft will be extended (or another draft written) to discuss
  37.     TCP mechanisms that are not yet on the IETF standards track.  These
  38.     mechanisms either need further research or have been determined to
  39.     be inappropriate for general purpose use on a shared network, but
  40.     may be beneficial for private satellite networks.
  41.  
  42. Abstract
  43.     
  44.     The Transmission Control Protocol (TCP) provides reliable delivery
  45.     of data across any network path, including network paths containing
  46.     satellite channels.  While TCP works over satellite channels there
  47.     are several mechanisms that enable TCP to more effectively utilize
  48.     the available capacity of the network path.  This draft outlines
  49.     some of these TCP mitigations.  At this time, all mitigations
  50.     discussed in this draft are IETF standards track mechanisms.
  51.  
  52. 1.  Introduction
  53.  
  54.     Satellite channel characteristics have an effect on the way
  55.     transport protocols, such as the Transmission Control Protocol (TCP)
  56.  
  57. Expires: April 2, 1998                                          [Page 1]
  58.  
  59. draft-tcpsat-stand-mech-00.txt                           October 2, 1997
  60.  
  61.     [Pos81], behave.  When protocols such as TCP perform poorly, channel
  62.     utilization is low.  This draft is divided up as follows: Section 2
  63.     provides a brief outline of the characteristics of satellite
  64.     networks.  Section 3 outlines two non-TCP mechanisms that enable TCP
  65.     to more effectively utilize the available bandwidth.  Section 4
  66.     outlines the TCP mechanisms defined by the IETF that benefit
  67.     satellite networks.  Finally, Section 5 provides a summary of what
  68.     modern TCP implementations should include to be considered
  69.     "satellite friendly".
  70.  
  71. 2.  Satellite Characteristics
  72.     
  73.     There is an inherent delay in the delivery of a message over a
  74.     satellite link due to the finite speed of light and the altitude of
  75.     communications satellites.
  76.  
  77.     Many communications satellites are located at Geostationary Orbit
  78.     (GSO) with an altitude of approximately 36,000 km [Sta94].  At this
  79.     altitude the orbit period is the same as the Earth's rotation
  80.     period.  Therefore, each ground station is always able to "see" the
  81.     orbiting satellite.  The propagation time for a radio signal to
  82.     travel twice that distance (corresponding to a ground station
  83.     directly below the satellite) is 239.6 milliseconds (ms) [Mar78].
  84.     For ground stations at the edge of the view area of the satellite,
  85.     the distance traveled is 2 x 41,756 km for a total propagation delay
  86.     of 279.0 ms [Mar78].  These delays are for one ground
  87.     station-to-satellite-to-ground station route (or "hop").  Therefore,
  88.     the propagation delay for a message and its reply (one round-trip
  89.     time or RTT) would be no more than 558 ms.  The delay will be
  90.     proportionately longer if the link includes multiple hops or if
  91.     intersatellite links are used.  As satellites become more complex
  92.     and include on-board processing of signals, additional delay may be
  93.     added.
  94.  
  95.     Other orbits are possible for use by communications satellites
  96.     including Low Earth Orbit (LEO) and Medium Earth Orbit (MEO)
  97.     [Mar78].  The lower orbits require the use of constellations of
  98.     satellites for constant coverage.  In other words, as one satellite
  99.     leaves the ground station's sight, another satellite appears on the
  100.     horizon and the channel is switched to it.  The propagation delay to
  101.     a LEO orbit ranges from several milliseconds when communicating with
  102.     a satellite directly overhead, to as much as 80 ms when the
  103.     satellite is on the horizon.  These systems are more likely to use
  104.     intersatellite links and have variable path delay depending on
  105.     routing through the network.
  106.  
  107.     Satellite channels are dominated by two fundamental characteristics,
  108.     as described below:
  109.  
  110.         NOISE - The strength of a radio signal falls in proportion to
  111.         the square of the distance traveled.  For a satellite link the
  112.         distance is large and so the signal becomes weak before reaching
  113.         it's destination.  This results in a low signal-to-noise ratio.
  114.         Typical bit error rates for a satellite link today are on the
  115.  
  116. Expires: April 2, 1998                                          [Page 2]
  117.  
  118. draft-tcpsat-stand-mech-00.txt                           October 2, 1997
  119.  
  120.         order of 10-7.  Satellite error performance equivalent to fiber
  121.         will become common as advanced error control coding is used in
  122.         new systems.  However, many current satellite systems do not
  123.         provide error free service.
  124.  
  125.         BANDWIDTH - The radio spectrum is a limited natural resource,
  126.         hence the bandwidth available to satellite systems is limited.
  127.         Typical carrier frequencies for current, point-to-point,
  128.         commercial, satellite services are 6 GHz (uplink) and 4 GHz
  129.         (downlink), also known as C band, and 14/12 GHz (Ku band).  A
  130.         new service at 30/20 GHz (Ka band) will be emerging over the
  131.         next few years.  Traditional C band transponder bandwidth is
  132.         typically 36 MHz to accommodate one color television channel (or
  133.         1200 voice channels).  Ku band transponders are typically around
  134.         50 MHz.  Furthermore, one satellite may carry a few dozen
  135.         transponders.
  136.  
  137.     Not only is bandwidth limited by nature, but the allocations for
  138.     commercial communications are limited by international agreements so
  139.     that this scarce resource can be used fairly by many different
  140.     applications.
  141.  
  142.     Although satellites have certain disadvantages when compared to
  143.     fiber channels, they also have certain advantages over terrestrial
  144.     links.  First, satellites have a natural broadcast capability.
  145.     Next, satellites can reach geographically remote areas or countries
  146.     that have little terrestrial infrastructure.  
  147.  
  148.     Satellite channels have several characteristics that differ from
  149.     most terrestrial channels.  These characteristics can degrade the
  150.     performance of TCP.  These characteristics include:
  151.     
  152.     Long feedback loop
  153.     
  154.         Due to the propagation delay of some satellite channels (e.g.,
  155.         approximately 250 ms over a geosynchronous satellite) it takes a
  156.         large amount of time for a TCP sender to determine whether or
  157.         not a packet has been successfully received at the final
  158.         destination.  This delay hurts interactive applications such as
  159.         telnet, as well as some of the TCP congestion control algorithms
  160.         (see section 4).
  161.  
  162.     Large delay*bandwidth product
  163.  
  164.         The delay*bandwidth product (DBP) defines the amount of data a
  165.         protocol should have "in flight" (data that has been
  166.         transmitted, but not yet acknowledged) at any one time to fully
  167.         utilize the available channel capacity.  Because the delay in
  168.         some satellite environments is large, TCP will need to keep a
  169.         large amount of data "in flight".
  170.  
  171.     
  172.  
  173.  
  174.  
  175. Expires: April 2, 1998                                          [Page 3]
  176.  
  177. draft-tcpsat-stand-mech-00.txt                           October 2, 1997
  178.  
  179.     Transmission errors
  180.     
  181.         Some satellite channels exhibit a higher bit-error rate (BER)
  182.         than typical terrestrial networks.  TCP uses all packet drops as
  183.         signals of congestion and reduces the sending rate.  Packets
  184.         dropped due to corruption do not indicate that the network is
  185.         congested.  However, the TCP sender cannot determine why a
  186.         packet was dropped and therefore will reduce the transmission
  187.         rate for all packet drops.
  188.  
  189.     Asymmetric use
  190.     
  191.         Due to the expense of the equipment used to send data to
  192.         satellites, asymmetric satellite networks are often constructed.
  193.         For example, a host connected to such a network will send all
  194.         outgoing traffic over a slow terrestrial link (such as a dialup
  195.         modem channel) and receive incoming traffic via the satellite
  196.         channel.  Another common situation arises when both the incoming
  197.         and outgoing traffic are sent using a satellite link, but the
  198.         uplink has less available capacity than the downlink.  This
  199.         asymmetry can have a large impact on TCP performance.
  200.  
  201.     Variable Round Trip Times
  202.     
  203.         In some satellite environments, such as low-Earth orbit (LEO)
  204.         constellations, the propagation delay to and from the satellite
  205.         varies over time.  This can have a negative impact on TCP's
  206.         ability to accurately set retransmission timeouts and determine
  207.         the appropriate window size.
  208.  
  209.     Intermittent connectivity
  210.  
  211.         In satellite orbit configurations, TCP connections must be
  212.         transfered from one satellite to another or from one ground
  213.         station to another from time to time.  This handoff can cause
  214.         packet loss.
  215.     
  216.         Most satellite channels only exhibit a subset of the above
  217.         characteristics.  In addition, some terrestrial networks exhibit
  218.         some of the above characteristics, as well.  The mechanisms
  219.         outlined in this document should benefits most networks,
  220.         especially those with one of the above characteristics.
  221.     
  222. 3.  Lower Level Mitigations
  223.  
  224.     It is recommended that those utilizing satellite channels in their
  225.     networks should use the following two non-TCP mechanisms which can
  226.     increase TCP performance.  These mechanisms are Path MTU Discovery
  227.     and forward error correction (FEC) and are outlined in the following
  228.     two sections.
  229.  
  230.     
  231.  
  232.  
  233.  
  234. Expires: April 2, 1998                                          [Page 4]
  235.  
  236. draft-tcpsat-stand-mech-00.txt                           October 2, 1997
  237.  
  238. 3.1 Path MTU Discovery
  239.     
  240.     Path MTU discovery [MD90] is used to determine the maximum packet
  241.     size a connection can use on a given network path without being
  242.     subjected to IP packet fragmentation.  The sender transmits a packet
  243.     that is the appropriate size for the local network with which it is
  244.     connected (e.g., 1500 bytes on an Ethernet) and sets the IP "don't
  245.     fragment" (DF) bit.  If the packet is too large for a channel along
  246.     the network path, the gateway that would normally fragment the
  247.     packet and forward the fragments will return an ICMP message to the
  248.     originator of the packet.  The ICMP message will indicate that the
  249.     original segment could not be transmitted without being fragmented
  250.     and will also contain the maximum size that can be forwarded by the
  251.     gateway.
  252.  
  253.     This allows TCP to use the largest possible packet size, without
  254.     incurring the cost of fragmentation and reassembly.  Large packets
  255.     reduce the packet overhead by sending more data bytes per overhead
  256.     byte.  Also, larger packets allow the slow start and congestion
  257.     avoidance algorithms to increase the congestion window more rapidly
  258.     (as outlined in section 4).
  259.     
  260.     The disadvantage of Path MTU Discovery is that it may cause a long
  261.     pause before TCP is able to start sending data.  For example, assume
  262.     a packet is sent with the DF bit set and one of the intervening
  263.     gateway (G1) returns an ICMP message indicating that it cannot
  264.     forward the segment.  At this point, the sending host reduces the
  265.     packet size to the size returned by G1 and sends another packet with
  266.     the DF bit set.  The packet will be forwarded by G1, however this
  267.     does not ensure all subsequent gateways in the network path will be
  268.     able to forward the segment.  If a second gateway (G2) can not
  269.     forward the segment it will return an ICMP message to the
  270.     transmitting host and the process will be repeated.  Therefore, path
  271.     MTU discovery can waste a large amount of time determining the
  272.     maximum allowable packet size on the network path and the network
  273.     topology.  However, in practice, Path MTU Discovery is not that
  274.     expensive.
  275.  
  276. 3.2 Forward Error Correction
  277.  
  278.     A loss event in TCP is always interpreted as an indication of
  279.     congestion and always causes TCP to reduce the window size.  When
  280.     loss occurs during slow start, then slow start is terminated and TCP
  281.     enters congestion avoidance.  Premature termination of slow start
  282.     and entry into congestion avoidance due to losses other than
  283.     congestion losses will cause needless inefficiency in channel
  284.     utilization.  Furthermore, drops due to corruption causes TCP to
  285.     needlessly reduce the amount of data being injected into the
  286.     network.  
  287.  
  288.     For TCP to operate efficiently, the channel characteristics should be
  289.     such that nearly all loss is due to network congestion.  The use of
  290.     forward error correction coding (FEC) on a satellite link should be
  291.     used to bring the performance of the link to at least fiber quality.
  292.  
  293. Expires: April 2, 1998                                          [Page 5]
  294.  
  295. draft-tcpsat-stand-mech-00.txt                           October 2, 1997
  296.  
  297.     Because of the effect of long RTT, errors on a satellite link have
  298.     more severe repercussions than on a lower RTT terrestrial channel
  299.     [PS97].  There are some applications, such as military jamming,
  300.     where FEC cannot be expected to solve the noise problem.  
  301.  
  302. 4.  Standard TCP Mechanisms
  303.  
  304.     This section includes an outline of the mechanisms that may be
  305.     necessary in satellite or hybrid satellite/terrestrial networks to
  306.     better utilize the available capacity of the link.  These mechanisms
  307.     may also be needed to fully utilize fast terrestrial channels.
  308.     Furthermore, these mechanisms do not fundamentally hurt performance
  309.     in a shared terrestrial network.  Each of the following sections
  310.     outlines one mechanism and why that mechanism may be needed.
  311.  
  312. 4.1 Congestion Control
  313.     
  314.     To avoid generating an inappropriate amount of network traffic for
  315.     the current network conditions TCP employs four congestion control
  316.     mechanisms [JK88] [Jac90] [Ste97].  These algorithms are slow start,
  317.     congestion avoidance, fast retransmit and fast recovery.  These
  318.     algorithms are used to adjust the amount of unacknowledged data that
  319.     can be injected into the network and to retransmit segments dropped
  320.     by the network.
  321.  
  322.     TCP uses two variables to accomplish congestion control.  The first
  323.     variable is the congestion window (cwnd).  This is an upper bound on
  324.     the amount of data the sender can inject into the network before
  325.     receiving an acknowledgment (ACK).  The value of cwnd is limited to
  326.     the receiver's advertised window.  The congestion window is
  327.     increased or decreased during the transfer based on the inferred
  328.     amount of congestion present in the network.  The second variable is
  329.     the slow start threshold (ssthresh).  This variable determines which
  330.     algorithm is being used to increase the value of cwnd.  If cwnd is
  331.     less than ssthresh the slow start algorithm is used to increase the
  332.     value of cwnd.  However, if cwnd is greater than or equal to
  333.     ssthresh the congestion avoidance algorithm is used.  The initial
  334.     value of ssthresh is the receiver's advertised window size.
  335.     Furthermore, the value of ssthresh is reduced when congestion is
  336.     detected. 
  337.  
  338.     The four congestion control algorithms are outlined below, followed
  339.     by a brief discussion of the impact of satellite environments on
  340.     these algorithms.
  341.  
  342. 4.1.1 Slow Start and Congestion Avoidance
  343.  
  344.     When a host begins sending data on a TCP connection the host has no
  345.     knowledge of the current state of the network between itself and the
  346.     data receiver.  In order to avoid transmitting an inappropriately
  347.     large burst of traffic, the data sender is required to use the slow
  348.     start algorithm at the beginning of a transfer [JK88] [Bra89]
  349.     [Ste97].  Slow start begins by initializing cwnd to 1 segment.  This
  350.     forces TCP to transmit one segment and wait for the corresponding
  351.  
  352. Expires: April 2, 1998                                          [Page 6]
  353.  
  354. draft-tcpsat-stand-mech-00.txt                           October 2, 1997
  355.  
  356.     ACK.  For each ACK that is received, the value of cwnd is increased
  357.     by 1 segment.  For example, after the first ACK is received cwnd
  358.     will be 2 segments and the sender will be allowed to transmit 2 data
  359.     packets.  This continues until cwnd meets or exceeds ssthresh, or
  360.     loss is detected.
  361.  
  362.     When the value of cwnd is greater than or equal to ssthresh the
  363.     congestion avoidance algorithm is used to increase cwnd [JK88]
  364.     [Bra89] [Ste97].  This algorithm increases the size of cwnd more
  365.     slowly than does slow start.  Congestion avoidance is used to probe
  366.     the network for any additional capacity.  During congestion
  367.     avoidance, cwnd is increased by 1/cwnd for each incoming ACK.
  368.     Therefore, if one ACK is received for every data segment, cwnd will
  369.     increase by 1 segment per round-trip time (RTT).
  370.     
  371.     Long-delay satellite networks force poor utilization of the
  372.     available channel bandwidth when using the slow start and congestion
  373.     control algorithms [All97].  For example, transmission begins with
  374.     the transmission of one segment.  After the first segment is
  375.     transmitted the data sender is forced to wait for the corresponding
  376.     ACK.  When using a GSO satellite this leads to an idle time of
  377.     roughly 500 ms when no useful work is being accomplished.
  378.     Therefore, slow start takes more real time over GSO satellites than
  379.     on typical terrestrial channels.  This holds for congestion
  380.     avoidance, as well [All97].  This is precisely why Path MTU Discovery
  381.     is an important algorithm.  While the number of segments we transmit
  382.     is determined by the congestion control algorithms, the size of
  383.     these segments is not.  Therefore, using larger packets will enable
  384.     TCP to send more data per segment which yields better channel
  385.     utilization.
  386.  
  387. 4.1.2 Fast Retransmit and Fast Recovery
  388.     
  389.     TCP's default mechanism to detect dropped segments is a timeout
  390.     [Pos81].  In other words, if the sender does not receive an ACK for
  391.     a given packet within the expected amount of time the segment will
  392.     be retransmitted.  The retransmission timeout (RTO) is based on
  393.     observations of the RTT.  In addition to retransmitting a segment
  394.     when the RTO expires, TCP also uses the lost segment as an
  395.     indication of congestion in the network.  In response to the
  396.     congestion, the value of ssthresh is set to half of the cwnd and the
  397.     value of cwnd is then reduced to 1 segment.  This triggers the use
  398.     of the slow start algorithm to increase cwnd until the value of cwnd
  399.     reaches half of its value when congestion was detected.  After the
  400.     slow start phase, the congestion avoidance algorithm is used to
  401.     probe the network for additional capacity.
  402.  
  403.     TCP ACKs always acknowledge the highest in-order segment that has
  404.     arrived.  Therefore an ACK for segment X also effectively ACKs all
  405.     segments < X.  Furthermore, if a segment arrives out-of-order the
  406.     ACK triggered will be for the highest in-order segment, rather than
  407.     the segment that just arrived.  For example, assume segment 11 has
  408.     been dropped somewhere in the network and segment 12 arrives at the
  409.     
  410.  
  411. Expires: April 2, 1998                                          [Page 7]
  412.  
  413. draft-tcpsat-stand-mech-00.txt                           October 2, 1997
  414.  
  415.     receiver.  The receiver is going to send a duplicate ACK covering
  416.     segment 10 (and all previous segments).
  417.     
  418.     The fast retransmit algorithm uses these duplicate ACKs to detect
  419.     lost segments.  If 3 duplicate ACKs arrive at the data originator,
  420.     TCP assumes that a segment has been lost and retransmits the missing
  421.     segment without waiting for the RTO to expire.  After a segment is
  422.     resent using fast retransmit, the fast recovery algorithm is used to
  423.     adjust the congestion window.  First, the value of ssthresh is set
  424.     to half of the value of cwnd.  Next, the value of cwnd is halved.
  425.     Finally, the value of cwnd is artificially increased by 1 segment
  426.     for each duplicate ACK that has arrived.  The artificial inflation
  427.     can be done because each duplicate ACK represents 1 segment that has
  428.     left the network.  When the cwnd permits, TCP is able to transmit
  429.     new data.  This allows TCP to keep data flowing through the network
  430.     at half the rate it was when loss was detected.  When an ACK for the
  431.     retransmitted packet arrives, the value of cwnd is reduced back to
  432.     ssthresh (half the value of cwnd when the congestion was detected).
  433.     
  434.     Fast retransmit can resend only one segment per window of data sent.
  435.     When multiple segments are lost in a given window of data, one of
  436.     the segments will be resent using fast retransmit and the rest of
  437.     the dropped segments must wait for the RTO to expire, which causes
  438.     TCP to revert to slow start.  
  439.  
  440.     TCP's response to congestion differs based on the way the congestion
  441.     was detected.  If the retransmission timer causes a packet to be
  442.     resent, TCP drops ssthresh to half the current cwnd and reduces the
  443.     value of cwnd to 1 segment (thus triggering slow start).  However,
  444.     if a segment is resent via fast retransmit both ssthresh and cwnd
  445.     are set to half the current value of cwnd and congestion avoidance
  446.     is used to send new data.  The difference is that when
  447.     retransmitting due to duplicate ACKs, TCP knows that packets are
  448.     still flowing through the network and can therefore infer that the
  449.     congestion is not that bad.  However, when resending a packet due to
  450.     a the expiration of the retransmission timer, TCP cannot infer
  451.     anything about the state of the network and therefore must proceed
  452.     conservatively by sending new data using the slow start algorithm.
  453.  
  454. 4.1.3 Congestion Control in Satellite Environment
  455.  
  456.     The above algorithms have a negative impact on the performance of
  457.     individual TCP connection's performance, especially over long-delay
  458.     satellite channels [All97] [AHKO97].  However, the algorithms are
  459.     necessary to prevent congestive collapse in a shared network [JK88].
  460.     Therefore, the negative impact on a given connection is more than
  461.     offset by the benefit to the entire network.
  462.  
  463.     
  464.  
  465.  
  466.  
  467.  
  468.  
  469.  
  470. Expires: April 2, 1998                                          [Page 8]
  471.  
  472. draft-tcpsat-stand-mech-00.txt                           October 2, 1997
  473.  
  474. 4.2 Large TCP Windows
  475.     
  476.     The standard TCP window size (65,535 bytes) is not adequate to allow
  477.     a single TCP connection to utilize the entire bandwidth available on
  478.     some satellite channels.  TCP throughput is limited by the following
  479.     formula [Pos81]:
  480.  
  481.     throughput = window size / RTT
  482.  
  483.     Therefore, using the maximum window size of 65,535 bytes and a
  484.     geosynchronous satellite channel RTT of 560 ms [Kru95] the maximum
  485.     throughput is limited to:
  486.  
  487.     throughput = 65,535 bytes / 560 ms = 117,027 bytes/second
  488.  
  489.     Therefore, a single standard TCP connection cannot fully utilize,
  490.     for example, T1 rate (192,000 bytes/second) GSO satellite channels.
  491.     However, TCP has been extended to support larger windows [JBB92].
  492.     The window scaling options outlined in [JBB92] should be used in
  493.     satellite environments, as well as the companion algorithms PAWS
  494.     (Protection Against Wrapped Sequence space) and RTTM (Round-Trip
  495.     Time Measurements).
  496.  
  497. 4.3 Selective Acknowledgments
  498.     
  499.     Selective acknowledgments (SACKs) [MMFR96] allow TCP receivers to
  500.     inform TCP senders exactly which packets have arrived.  TCP senders
  501.     that do not use SACKs must infer which segments have not arrived and
  502.     retransmit accordingly.  This can lead to needless retransmissions,
  503.     in the case when the sender infers incorrectly.  When utilizing
  504.     SACKs, the sender does not need to guess which segments have not
  505.     arrived.
  506.     
  507.     Some satellite channels require the use of large TCP windows to
  508.     fully utilize the available capacity, as discussed above.  With the
  509.     use of large windows, the likelihood of losing multiple segments in
  510.     a given window of data increases.  When multiple segments are lost,
  511.     SACKs will ensure the data sender retransmits only those segments
  512.     that were dropped and not those that safely arrived at the
  513.     receiver. 
  514.  
  515. 5.  Mitigation Summary
  516.     
  517.     Table 1 summarizes the mechanisms that have been discussed in this
  518.     document.  Those mechanisms denoted "Recommended" are IETF standards
  519.     track mechanisms that are recommended by the authors for use in
  520.     networks containing satellite channels.  Those mechanisms marked
  521.     "Required" have been defined by the IETF as required for hosts using
  522.     the shared Internet [Bra89].
  523.     
  524.     Satellite users should check with their TCP vendors (implementors)
  525.     to ensure the recommended mechanisms are supported in their stack in
  526.     current and/or future versions.
  527.  
  528.  
  529. Expires: April 2, 1998                                          [Page 9]
  530.  
  531. draft-tcpsat-stand-mech-00.txt                           October 2, 1997
  532.  
  533.     Work on improving the efficiency of TCP over satellite channels is
  534.     ongoing and will be summarized in a planned memo along with other
  535.     considerations, such as network architectures.
  536.  
  537.          Mechanism                 Use          Section 
  538.         +------------------------+-------------+------------+
  539.         | Path-MTU Discovery     | Recommended | 3.1        |
  540.         | FEC                    | Recommended | 3.2        |
  541.         | TCP Congestion Control |             |            |
  542.         |   Slow Start           | Required    | 4.1.1      |
  543.         |   Congestion Avoidance | Required    | 4.1.1      |
  544.         |   Fast Retransmit      | Recommended | 4.1.2      |
  545.         |   Fast Recovery        | Recommended | 4.1.2      |
  546.         | TCP Large Windows      |             |            |
  547.         |   Window Scaling       | Recommended | 4.2        |
  548.         |   PAWS                 | Recommended | 4.2        |
  549.         |   RTTM                 | Recommended | 4.2        |
  550.         | TCP SACKs              | Recommended | 4.3        |
  551.         +------------------------+-------------+------------+
  552.                                 Table 1
  553.  
  554. 6.  Security
  555.  
  556.     The recommendations contained in this memo do not alter the security
  557.     implications of TCP.
  558.  
  559. References
  560.  
  561.     [AHKO97] Mark Allman, Chris Hayes, Hans Kruse, and Shawn Ostermann.
  562.         TCP Performance Over Satellite Links.  In Proceedings of the 5th
  563.         International Conference on Telecommunication Systems, March
  564.         1997.
  565.  
  566.     [All97] Mark Allman.  Improving TCP Performance Over Satellite
  567.         Channels.  Master's thesis, Ohio University, June 1997.
  568.  
  569.  
  570.     [Bra89] Robert Braden.  Requirements for Internet Hosts --
  571.         Communication Layers, October 1989.  RFC 1122.
  572.  
  573.     [Jac90] Van Jacobson.  Modified TCP Congestion Avoidance Algorithm.
  574.         Technical Report, LBL, April 1990.
  575.  
  576.     [JBB92] Van Jacobson, Robert Braden, and David Borman.  TCP
  577.         Extensions for High Performance, May 1992.  RFC 1323.
  578.  
  579.     [JK88] Van Jacobson and Michael Karels.  Congestion Avoidance and
  580.         Control.  In ACM SIGCOMM, 1988.
  581.  
  582.     [Mar78] James Martin.  Communications Satellite Systems.  Prentice
  583.         Hall, 1978.
  584.  
  585.     [MD90] Jeff Mogul and Steve Deering.  Path MTU Discovery, November
  586.         1990.  RFC 1191.
  587.  
  588. Expires: April 2, 1998                                         [Page 10]
  589.  
  590. draft-tcpsat-stand-mech-00.txt                           October 2, 1997
  591.  
  592.  
  593.     [MMFR96] Matt Mathis, Jamshid Mahdavi, Sally Floyd, and Allyn
  594.         Romanow.  TCP Selective Acknowledgment Options, October 1996.
  595.         RFC 2018.
  596.  
  597.     [Pos81] Jon Postel.  Transmission Control Protocol, September 1981.
  598.         RFC 793.
  599.  
  600.     [PS97] Craig Partridge and Tim Shepard.  TCP Performance Over
  601.         Satellite Links.  IEEE Network, 11(5), September/October 1997.
  602.  
  603.     [Sta94] William Stallings.  Data and Computer Communications.
  604.         MacMillian, 4th edition, 1994.
  605.  
  606.     [Ste97] W. Richard Stevens.  TCP Slow Start, Congestion Avoidance,
  607.         Fast Retransmit, and Fast Recovery Algorithms, January 1997.
  608.         RFC 2001.
  609.  
  610. Author's Addresses:
  611.  
  612.     Mark Allman
  613.     NASA Lewis Research Center/Sterling Software
  614.     21000 Brookpark Rd.  MS 54-2
  615.     Cleveland, OH  44135
  616.     mallman@lerc.nasa.gov
  617.     http://gigahertz.lerc.nasa.gov/~mallman
  618.  
  619.     Dan Glover 
  620.     NASA Lewis Research Center
  621.     21000 Brookpark Rd.  MS 54-2
  622.     Cleveland, OH  44135
  623.     Daniel.R.Glover@lerc.nasa.gov
  624.  
  625.  
  626.  
  627.  
  628.  
  629.  
  630.  
  631.  
  632.  
  633.  
  634.  
  635.  
  636.  
  637.  
  638.  
  639.  
  640.  
  641.  
  642.  
  643.  
  644.  
  645.  
  646.  
  647. Expires: April 2, 1998                                         [Page 11]
  648.  
  649.