rfc2760.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

Network Working Group                                  M. Allman, Editor
Request for Comments: 2760   NASA Glenn Research Center/BBN Technologies
Category: Informational                                       S. Dawkins
                                                                  Nortel
                                                               D. Glover
                                                               J. Griner
                                                                 D. Tran
                                              NASA Glenn Research Center
                                                            T. Henderson
                                    University of California at Berkeley
                                                            J. Heidemann
                                                                J. Touch
                                   University of Southern California/ISI
                                                                H. Kruse
                                                            S. Ostermann
                                                         Ohio University
                                                                K. Scott
                                                   The MITRE Corporation
                                                                J. Semke
                                        Pittsburgh Supercomputing Center
                                                           February 2000


               Ongoing TCP Research Related to Satellites


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 document outlines possible TCP enhancements that may allow TCP
   to better utilize the available bandwidth provided by networks
   containing satellite links.  The algorithms and mechanisms outlined
   have not been judged to be mature enough to be recommended by the
   IETF.  The goal of this document is to educate researchers as to the
   current work and progress being done in TCP research related to
   satellite networks.






Allman, et al.               Informational                      [Page 1]

RFC 2760       Ongoing TCP Research Related to Satellites  February 2000


Table of Contents

   1         Introduction. . . . . . . . . . . . . . . . . . . .  2
   2         Satellite Architectures . . . . . . . . . . . . . .  3
   2.1       Asymmetric Satellite Networks . . . . . . . . . . .  3
   2.2       Satellite Link as Last Hop. . . . . . . . . . . . .  3
   2.3       Hybrid Satellite Networks     . . . . . . . . . . .  4
   2.4       Point-to-Point Satellite Networks . . . . . . . . .  4
   2.5       Multiple Satellite Hops . . . . . . . . . . . . . .  4
   3         Mitigations . . . . . . . . . . . . . . . . . . . .  4
   3.1       TCP For Transactions. . . . . . . . . . . . . . . .  4
   3.2       Slow Start. . . . . . . . . . . . . . . . . . . . .  5
   3.2.1     Larger Initial Window . . . . . . . . . . . . . . .  6
   3.2.2     Byte Counting . . . . . . . . . . . . . . . . . . .  7
   3.2.3     Delayed ACKs After Slow Start . . . . . . . . . . .  9
   3.2.4     Terminating Slow Start. . . . . . . . . . . . . . . 11
   3.3       Loss Recovery . . . . . . . . . . . . . . . . . . . 12
   3.3.1     Non-SACK Based Mechanisms . . . . . . . . . . . . . 12
   3.3.2     SACK Based Mechanisms . . . . . . . . . . . . . . . 13
   3.3.3     Explicit Congestion Notification. . . . . . . . . . 16
   3.3.4     Detecting Corruption Loss . . . . . . . . . . . . . 18
   3.4       Congestion Avoidance. . . . . . . . . . . . . . . . 21
   3.5       Multiple Data Connections . . . . . . . . . . . . . 22
   3.6       Pacing TCP Segments . . . . . . . . . . . . . . . . 24
   3.7       TCP Header Compression. . . . . . . . . . . . . . . 26
   3.8       Sharing TCP State Among Similar Connections . . . . 29
   3.9       ACK Congestion Control. . . . . . . . . . . . . . . 32
   3.10      ACK Filtering . . . . . . . . . . . . . . . . . . . 34
   4         Conclusions . . . . . . . . . . . . . . . . . . . . 36
   5         Security Considerations . . . . . . . . . . . . . . 36
   6         Acknowledgments . . . . . . . . . . . . . . . . . . 37
   7         References. . . . . . . . . . . . . . . . . . . . . 37
   8         Authors' Addresses. . . . . . . . . . . . . . . . . 43
   9         Full Copyright Statement. . . . . . . . . . . . . . 46

1   Introduction

   This document outlines mechanisms that may help the Transmission
   Control Protocol (TCP) [Pos81] better utilize the bandwidth provided
   by long-delay satellite environments.  These mechanisms may also help
   in other environments or for other protocols.  The proposals outlined
   in this document are currently being studied throughout the research
   community.  Therefore, these mechanisms are not mature enough to be
   recommended for wide-spread use by the IETF.  However, some of these
   mechanisms may be safely used today.  It is hoped that this document
   will stimulate further study into the described mechanisms.  If, at





Allman, et al.               Informational                      [Page 2]

RFC 2760       Ongoing TCP Research Related to Satellites  February 2000


   some point, the mechanisms discussed in this memo prove to be safe
   and appropriate to be recommended for general use, the appropriate
   IETF documents will be written.

   It should be noted that non-TCP mechanisms that help performance over
   satellite links do exist (e.g., application-level changes, queueing
   disciplines, etc.).  However, outlining these non-TCP mitigations is
   beyond the scope of this document and therefore is left as future
   work.  Additionally, there are a number of mitigations to TCP's
   performance problems that involve very active intervention by
   gateways along the end-to-end path from the sender to the receiver.
   Documenting the pros and cons of such solutions is also left as
   future work.

2   Satellite Architectures

   Specific characteristics of satellite links and the impact these
   characteristics have on TCP are presented in RFC 2488 [AGS99].  This
   section discusses several possible topologies where satellite links
   may be integrated into the global Internet.  The mitigation outlined
   in section 3 will include a discussion of which environment the
   mechanism is expected to benefit.

2.1 Asymmetric Satellite Networks

   Some satellite networks exhibit a bandwidth asymmetry, a larger data
   rate in one direction than the reverse direction, because of limits
   on the transmission power and the antenna size at one end of the
   link.  Meanwhile, some other satellite systems are unidirectional and
   use a non-satellite return path (such as a dialup modem link).  The
   nature of most TCP traffic is asymmetric with data flowing in one
   direction and acknowledgments in opposite direction.  However, the
   term asymmetric in this document refers to different physical
   capacities in the forward and return links.  Asymmetry has been shown
   to be a problem for TCP [BPK97,BPK98].

2.2 Satellite Link as Last Hop

   Satellite links that provide service directly to end users, as
   opposed to satellite links located in the middle of a network, may
   allow for specialized design of protocols used over the last hop.
   Some satellite providers use the satellite link as a shared high
   speed downlink to users with a lower speed, non-shared terrestrial
   link that is used as a return link for requests and acknowledgments.
   Many times this creates an asymmetric network, as discussed above.






Allman, et al.               Informational                      [Page 3]

RFC 2760       Ongoing TCP Research Related to Satellites  February 2000


2.3 Hybrid Satellite Networks

   In the more general case, satellite links may be located at any point
   in the network topology.  In this case, the satellite link acts as
   just another link between two gateways.  In this environment, a given
   connection may be sent over terrestrial links (including terrestrial
   wireless), as well as satellite links.  On the other hand, a
   connection could also travel over only the terrestrial network or
   only over the satellite portion of the network.

2.4 Point-to-Point Satellite Networks

   In point-to-point satellite networks, the only hop in the network is
   over the satellite link.  This pure satellite environment exhibits
   only the problems associated with the satellite links, as outlined in
   [AGS99].  Since this is a private network, some mitigations that are
   not appropriate for shared networks can be considered.

2.5 Multiple Satellite Hops

   In some situations, network traffic may traverse multiple satellite
   hops between the source and the destination.  Such an environment
   aggravates the satellite characteristics described in [AGS99].

3   Mitigations

   The following sections will discuss various techniques for mitigating
   the problems TCP faces in the satellite environment.  Each of the
   following sections will be organized as follows: First, each
   mitigation will be briefly outlined.  Next, research work involving
   the mechanism in question will be briefly discussed.  Next the
   implementation issues of the mechanism will be presented (including
   whether or not the particular mechanism presents any dangers to
   shared networks).  Then a discussion of the mechanism's potential
   with regard to the topologies outlined above is given.  Finally, the
   relationships and possible interactions with other TCP mechanisms are
   outlined.  The reader is expected to be familiar with the TCP
   terminology used in [AGS99].

3.1 TCP For Transactions

3.1.1 Mitigation Description

   TCP uses a three-way handshake to setup a connection between two
   hosts [Pos81].  This connection setup requires 1-1.5 round-trip times
   (RTTs), depending upon whether the data sender started the connection
   actively or passively.  This startup time can be eliminated by using
   TCP extensions for transactions (T/TCP) [Bra94].  After the first



Allman, et al.               Informational                      [Page 4]

RFC 2760       Ongoing TCP Research Related to Satellites  February 2000


   connection between a pair of hosts is established, T/TCP is able to
   bypass the three-way handshake, allowing the data sender to begin
   transmitting data in the first segment sent (along with the SYN).
   This is especially helpful for short request/response traffic, as it
   saves a potentially long setup phase when no useful data is being
   transmitted.

3.1.2 Research

   T/TCP is outlined and analyzed in [Bra92,Bra94].

3.1.3 Implementation Issues

   T/TCP requires changes in the TCP stacks of both the data sender and
   the data receiver.  While T/TCP is safe to implement in shared
   networks from a congestion control perspective, several security
   implications of sending data in the first data segment have been
   identified [ddKI99].

3.1.4 Topology Considerations

   It is expected that T/TCP will be equally beneficial in all
   environments outlined in section 2.

3.1.5 Possible Interaction and Relationships with Other Research

   T/TCP allows data transfer to start more rapidly, much like using a
   larger initial congestion window (see section 3.2.1), delayed ACKs
   after slow start (section 3.2.3) or byte counting (section 3.2.2).

3.2 Slow Start

   The slow start algorithm is used to gradually increase the size of
   TCP's congestion window (cwnd) [Jac88,Ste97,APS99].  The algorithm is
   an important safe-guard against transmitting an inappropriate amount
   of data into the network when the connection starts up.  However,
   slow start can also waste available network capacity, especially in
   long-delay networks [All97a,Hay97].  Slow start is particularly
   inefficient for transfers that are short compared to the
   delay*bandwidth product of the network (e.g., WWW transfers).

   Delayed ACKs are another source of wasted capacity during the slow
   start phase.  RFC 1122 [Bra89] suggests data receivers refrain from
   ACKing every incoming data segment.  However, every second full-sized
   segment should be ACKed.  If a second full-sized segment does not
   arrive within a given timeout, an ACK must be generated (this timeout
   cannot exceed 500 ms).  Since the data sender increases the size of
   cwnd based on the number of arriving ACKs, reducing the number of



Allman, et al.               Informational                      [Page 5]

RFC 2760       Ongoing TCP Research Related to Satellites  February 2000