rfc2757.txt

RFC 的详细文档！

Network Working Group                                      G. Montenegro
Request for Comments: 2757                        Sun Microsystems, Inc.
Category: Informational                                       S. Dawkins
                                                         Nortel Networks
                                                                 M. Kojo
                                                  University of Helsinki
                                                               V. Magret
                                                                 Alcatel
                                                               N. Vaidya
                                                    Texas A&M University
                                                            January 2000


                           Long Thin Networks

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

   In view of the unpredictable and problematic nature of long thin
   networks (for example, wireless WANs), arriving at an optimized
   transport is a daunting task.  We have reviewed the existing
   proposals along with future research items. Based on this overview,
   we also recommend mechanisms for implementation in long thin
   networks.

   Our goal is to identify a TCP that works for all users, including
   users of long thin networks. We started from the working
   recommendations of the IETF TCP Over Satellite Links (tcpsat) working
   group with this end in mind.

   We recognize that not every tcpsat recommendation will be required
   for long thin networks as well, and work toward a set of TCP
   recommendations that are 'benign' in environments that do not require
   them.








Montenegro, et al.           Informational                      [Page 1]

RFC 2757                   Long Thin Networks               January 2000


Table of Contents

   1 Introduction .................................................    3
      1.1 Network Architecture ....................................    5
      1.2 Assumptions about the Radio Link ........................    6
   2 Should it be IP or Not?  .....................................    7
      2.1 Underlying Network Error Characteristics ................    7
      2.2 Non-IP Alternatives .....................................    8
         2.2.1 WAP ................................................    8
         2.2.2 Deploying Non-IP Alternatives ......................    9
      2.3 IP-based Considerations .................................    9
         2.3.1 Choosing the MTU [Stevens94, RFC1144] ..............    9
         2.3.2 Path MTU Discovery [RFC1191] .......................   10
         2.3.3 Non-TCP Proposals ..................................   10
   3 The Case for TCP .............................................   11
   4 Candidate Optimizations ......................................   12
      4.1 TCP: Current Mechanisms .................................   12
         4.1.1 Slow Start and Congestion Avoidance ................   12
         4.1.2 Fast Retransmit and Fast Recovery ..................   12
      4.2 Connection Setup with T/TCP [RFC1397, RFC1644] ..........   14
      4.3 Slow Start Proposals ....................................   14
         4.3.1 Larger Initial Window ..............................   14
         4.3.2 Growing the Window during Slow Start ...............   15
            4.3.2.1 ACK Counting ..................................   15
            4.3.2.2 ACK-every-segment .............................   16
         4.3.3 Terminating Slow Start .............................   17
         4.3.4 Generating ACKs during Slow Start ..................   17
      4.4 ACK Spacing .............................................   17
      4.5 Delayed Duplicate Acknowlegements .......................   18
      4.6 Selective Acknowledgements [RFC2018] ....................   18
      4.7 Detecting Corruption Loss ...............................   19
         4.7.1 Without Explicit Notification ......................   19
         4.7.2 With Explicit Notifications ........................   20
      4.8 Active Queue Management .................................   21
      4.9 Scheduling Algorithms ...................................   21
      4.10 Split TCP and Performance-Enhancing Proxies (PEPs) .....   22
         4.10.1 Split TCP Approaches ..............................   23
         4.10.2 Application Level Proxies .........................   26
         4.10.3 Snoop and its Derivatives .........................   27
         4.10.4 PEPs to handle Periods of Disconnection ...........   29
      4.11 Header Compression Alternatives ........................   30
      4.12 Payload Compression ....................................   31
      4.13 TCP Control Block Interdependence [Touch97] ............   32
   5 Summary of Recommended Optimizations .........................   33
   6 Conclusion ...................................................   35
   7 Acknowledgements .............................................   35
   8 Security Considerations ......................................   35




Montenegro, et al.           Informational                      [Page 2]

RFC 2757                   Long Thin Networks               January 2000


   9 References ...................................................   36
   Authors' Addresses .............................................   44
   Full Copyright Statement .......................................   46

1 Introduction

   Optimized wireless networking is one of the major hurdles that Mobile
   Computing must solve if it is to enable ubiquitous access to
   networking resources. However, current data networking protocols have
   been optimized primarily for wired networks.  Wireless environments
   have very different characteristics in terms of latency, jitter, and
   error rate as compared to wired networks.  Accordingly, traditional
   protocols are ill-suited to this medium.

   Mobile Wireless networks can be grouped in W-LANs (for example,
   802.11 compliant networks) and W-WANs (for example, CDPD [CDPD],
   Ricochet, CDMA [CDMA], PHS, DoCoMo, GSM [GSM] to name a few).  W-WANs
   present the most serious challenge, given that the length of the
   wireless link (expressed as the delay*bandwidth product) is typically
   4 to 5 times as long as that of its W-LAN counterparts.  For example,
   for an 802.11 network, assuming the delay (round-trip time) is about
   3 ms.  and the bandwidth is 1.5 Mbps, the delay*bandwidth product is
   4500 bits. For a W-WAN such as Ricochet, a typical round-trip time
   may be around 500 ms. (the best is about 230 ms.), and the sustained
   bandwidth is about 24 Kbps. This yields a delay*bandwidth product
   roughly equal to 1.5 KB. In the near future, 3rd Generation wireless
   services will offer 384Kbps and more.  Assuming a 200 ms round-trip,
   the delay*bandwidth product in this case is 76.8 Kbits (9.6 KB). This
   value is larger than the default 8KB buffer space used by many TCP
   implementations. This means that, whereas for W-LANs the default
   buffer space is enough, future W-WANs will operate inefficiently
   (that is, they will not be able to fill the pipe) unless they
   override the default value. A 3rd Generation wireless service
   offering 2 Mbps with 200-millisecond latency requires a 50 KB buffer.

   Most importantly,  latency across a link adversely affects
   throughput. For example,  [MSMO97] derives an upper bound on TCP
   throughput. Indeed, the resultant expression is inversely related to
   the round-trip time.

   The long latencies also push the limits (and commonly transgress
   them) for what is acceptable to users of interactive applications.

   As a quick glance to our list of references will reveal, there is a
   wealth of proposals that attempt to solve the wireless networking
   problem. In this document, we survey the different solutions
   available or under investigation, and issue the corresponding
   recommendations.



Montenegro, et al.           Informational                      [Page 3]

RFC 2757                   Long Thin Networks               January 2000


   There is a large body of work on the subject of improving TCP
   performance over satellite links. The documents under development by
   the tcpsat working group of the IETF [AGS98, ADGGHOSSTT98] are very
   relevant. In both cases, it is essential to start by improving the
   characteristics of the medium by using forward error correction (FEC)
   at the link layer to reduce the BER (bit error rate) from values as
   high as 10-3 to 10-6 or better. This makes the BER manageable. Once
   in this realm, retransmission schemes like ARQ (automatic repeat
   request) may be used to bring it down even further. Notice that
   sometimes it may be desirable to forego ARQ because of the additional
   delay it implies.  In particular, time sensitive traffic (video,
   audio) must be delivered within a certain time limit beyond which the
   data is obsolete. Exhaustive retransmissions in this case merely
   succeed in wasting time in order to deliver data that will be
   discarded once it arrives at its destination.  This indicates the
   desirability of augmenting the protocol stack implementation on
   devices such that the upper protocol layers can inform the link and
   MAC layer when to avoid such costly retransmission schemes.

   Networks that include satellite links are examples of "long fat
   networks" (LFNs or "elephants"). They are "long" networks because
   their round-trip time is quite high (for example, 0.5 sec and higher
   for geosynchronous satellites). Not all satellite links fall within
   the LFN regime. In particular, round-trip times in a low-earth
   orbiting (LEO) satellite network may be as little as a few
   milliseconds (and never extend beyond 160 to 200 ms). W-WANs share
   the "L" with LFNs. However, satellite networks are also "fat" in the
   sense that they may have high bandwidth. Satellite networks may often
   have a delay*bandwidth product above 64 KBytes, in which case they
   pose additional problems to TCP [TCPHP]. W-WANs do not generally
   exhibit this behavior. Accordingly, this document only deals with
   links that are "long thin pipes", and the networks that contain them:
   "long thin networks". We call these "LTNs".

   This document does not give an overview of the API used to access the
   underlying transport. We believe this is an orthogonal issue, even
   though some of the proposals below have been put forth assuming a
   given interface.  It is possible, for example, to support the
   traditional socket semantics without fully relying on TCP/IP
   transport [MOWGLI].

   Our focus is on the on-the-wire protocols. We try to include the most
   relevant ones and briefly (given that we provide the references
   needed for further study) mention their most salient points.







Montenegro, et al.           Informational                      [Page 4]

RFC 2757                   Long Thin Networks               January 2000


1.1 Network Architecture

   One significant difference between LFNs and LTNs is that we assume
   the W-WAN link is the last hop to the end user. This allows us to
   assume that a single intermediate node sees all packets transferred
   between the wireless mobile device and the rest of the Internet.
   This is only one of the topologies considered by the TCP Satellite
   community.

   Given our focus on mobile wireless applications, we only consider a
   very specific architecture that includes:

      -  a wireless mobile device, connected via

      -  a wireless link (which may, in fact comprise several hops at
         the link layer), to

      -  an intermediate node (sometimes referred to as a base station)
         connected via

      -  a wireline link, which in turn interfaces with

      -  the landline Internet and millions of legacy servers and web
         sites.

   Specifically, we are not as concerned with paths that include two
   wireless segments separated by a wired one. This may occur, for
   example, if one mobile device connects across its immediate wireless
   segment via an intermediate node to the Internet, and then via a
   second wireless segment to another mobile device.  Quite often,
   mobile devices connect to a legacy server on the wired Internet.

   Typically, the endpoints of the wireless segment are the intermediate
   node and the mobile device. However, the latter may be a wireless
   router to a mobile network. This is also important and has
   applications in, for example, disaster recovery.

   Our target architecture has implications which concern the
   deployability of candidate solutions. In particular, an important
   requirement is that we cannot alter the networking stack on the
   legacy servers. It would be preferable to only change the networking
   stack at the intermediate node, although changing it at the mobile
   devices is certainly an option and perhaps a necessity.

   We envision mobile devices that can use the wireless medium very
   efficiently, but overcome some of its traditional constraints.  That
   is, full mobility implies that the devices have the flexibility and
   agility to use whichever happens to be the best network connection



Montenegro, et al.           Informational                      [Page 5]