rfc2757.txt

中、英文RFC文档大全打包下载完全版 .

      -  Avoid lock-outs. Lack of resources in a router (and the
         resultant packet drops) may, in effect, obliterate throughput
         on certain connections.  Because of active queue management, it
         is more probable for an incoming packet to find available
         buffer space at the router.

   Active Queue Management has two components: (1) routers detect
   congestion before exhausting their resources, and (2) they provide
   some form of congestion indication. Dropping packets via RED is only
   one example of the latter.  Another way to indicate congestion is to
   use ECN [ECN] as discussed above under "Detecting Corruption Loss:
   With Explicit Notifications."

   Recommendation: RED is currently being deployed in the Internet, and
   LTNs should follow suit. ECN deployment should complement RED's.

4.9 Scheduling Algorithms

   Active queue management helps control the length of the queues.
   Additionally, a general solution requires replacing FIFO with other
   scheduling algorithms that improve:




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


      1. Fairness (by policing how different packet streams utilize the
         available bandwidth), and

      2. Throughput (by improving the transmitter's radio channel
         utilization).

   For example, fairness is necessary for interactive applications (like
   telnet or web browsing) to coexist with bulk transfer sessions.
   Proposals here include:

      - Fair Queueing (FQ) [Demers90]

      - Class-based Queueing (CBQ) [Floyd95]

   Even if they are only implemented over the wireless link portion of
   the communication path, these proposals are attractive in wireless
   LTN environments, because new connections for interactive
   applications can have difficulty starting when a bulk TCP transfer
   has already stabilized using all available bandwidth.

   In our base architecture described above, the mobile device typically
   communicates directly with only one wireless peer at a given time:
   the intermediate node. In some W-WANs, it is possible to directly
   address other mobiles within the same cell.  Direct communication
   with each such wireless peer may traverse a spatially distinct path,
   each of which may exhibit statistically independent radio link
   characteristics. Channel State Dependent Packet Scheduling (CSDP)
   [BBKT96] tracks the state of the various radio links (as defined by
   the target devices), and gives preferential treatment to packets
   destined for radio links in a "good" state. This avoids attempting to
   transmit to (and expect acknowledgements from) a peer on a "bad"
   radio link, thus improving throughput.

   A further refinement of this idea suggests that both fairness and
   throughput can be improved by combining a wireless-enhanced CBQ with
   CSDP [FSS98].

   Recommendation: No recommendation at this time, pending further
   study.

4.10 Split TCP and Performance-Enhancing Proxies (PEPs)

   Given the dramatic differences between the wired and the wireless
   links, a very common approach is to provide some impedance matching
   where the two different technologies meet: at the intermediate node.






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


   The idea is to replace an end-to-end TCP connection with two clearly
   distinct connections: one across the wireless link, the other across
   its wireline counterpart. Each of the two resulting TCP sessions
   operates under very different networking characteristics, and may
   adopt the policies best suited to its particular medium.  For
   example, in a specific LTN topology it may be desirable to modify TCP
   Fast Retransmit to resend after the first duplicate ack and Fast
   Recovery to not shrink the congestion window if the LTN link has an
   extremely long RTT, is known to not reorder packets, and is not
   subject to congestion. Moreover, on a long-delay link or on a link
   with a relatively high bandwidth-delay product it may be desirable to
   "slow-start" with a relatively large initial window, even larger than
   four segments.  While these kinds of TCP modifications can be
   negotiated to be employed over the LTN link, they would not be
   deployed end-to-end over the global Internet. In LTN topologies where
   the underlying link characteristics are known, a various similar
   types of performance enhancements can be employed without endangering
   operations over the global Internet.

   In some proposals, in addition to a PEP mechanism at the intermediate
   node, custom protocols are used on the wireless link (for example,
   [WAP], [YB94] or [MOWGLI]).

   Even if the gains from using non-TCP protocols are moderate or
   better, the wealth of research on optimizing TCP for wireless, and
   compatibility with the Internet are compelling reasons to adopt TCP
   on the wireless link (enhanced as suggested in section 5 below).

4.10.1 Split TCP Approaches

   Split-TCP proposals include schemes like I-TCP [ITCP] and MTCP [YB94]
   which achieve performance improvements by abandoning end-to-end
   semantics.

   The Mowgli architecture [MOWGLI] proposes a split approach with
   support for various enhancements at all the protocol layers, not only
   at the transport layer. Mowgli provides an option to replace the
   TCP/IP core protocols on the LTN link with a custom protocol that is
   tuned for LTN links [KRLKA97].  In addition, the protocol provides
   various features that are useful with LTNs. For example, it provides
   priority-based multiplexing of concurrent connections together with
   shared flow control, thus offering link capacity to interactive
   applications in a timely manner even if there are bandwidth-intensive
   background transfers.  Also with this option, Mowgli preserves the
   socket semantics on the mobile device so that legacy applications can
   be run unmodified.





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


   Employing split TCP approaches have several benefits as well as
   drawbacks. Benefits related to split TCP approaches include the
   following:

   -  Splitting the end-to-end TCP connection into two parts is a
      straightforward way to shield the problems of the wireless link
      from the wireline Internet path, and vice versa. Thus, a split TCP
      approach enables applying local solutions to the local problems on
      the wireless link.  For example, it automatically solves the
      problem of distinguishing congestion related packet losses on the
      wireline Internet and packet losses due to transmission error on
      the wireless link as these occur on separate TCP connections.
      Even if both segments experience congestion, it may be of a
      different nature and may be treated as such.  Moreover, temporary
      disconnections of the wireless link can be effectively shielded
      from the wireline Internet.

   -  When one of the TCP connections crosses only a single hop wireless
      link or a very limited number of hops, some or all link
      characteristics for the wireless TCP path are known. For example,
      with a particular link we may know that the link provides reliable
      delivery of packets, packets are not delivered out of order, or
      the link is not subject to congestion. Having this information for
      the TCP path one could expect that defining the TCP mitigations to
      be employed becomes a significantly easier task. In addition,
      several mitigations that cannot be employed safely over the global
      Internet, can be successfully employed over the wireless link.

   -  Splitting one TCP connection into two separate ones allows much
      earlier deployment of various recent proposals to improve TCP
      performance over wireless links; only the TCP implementations of
      the mobile device and intermediate node need to be modified, thus
      allowing the vast number of Internet hosts to continue running the
      legacy TCP implementations unmodified. Any mitigations that would
      require modification of TCP in these wireline hosts may take far
      too long to become widely deployed.

   -  Allows exploitation of various application level enhancements
      which may give significant performance gains (see section 4.10.2).

   Drawbacks related to split TCP approaches include the following:

   -  One of the main criticisms against the split TCP approaches is
      that it breaks TCP end-to-end semantics. This has various
      drawbacks some of which are more severe than others. The most
      detrimental drawback is probably that splitting the TCP connection
      disables end-to-end usage of IP layer security mechanisms,
      precluding the application of IPSec to achieve end-to-end



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


      security. Still, IPSec could be employed separately in each of the
      two parts, thus requiring the intermediate node to become a party
      to the security association between the mobile device and the
      remote host. This, however, is an undesirable or unacceptable
      alternative in most cases. Other security mechanisms above the
      transport layer, like TLS [RFC2246] or SOCKS [RFC1928], should be
      employed for end-to-end security.

   -  Another drawback of breaking end-to-end semantics is that crashes
      of the intermediate node become unrecoverable resulting in
      termination of the TCP connections. Whether this should be
      considered a severe problem depends on the expected frequency of
      such crashes.

   -  In many occasions claims have been stated that if TCP end-to-end
      semantics is broken, applications relying on TCP to provide
      reliable data delivery become more vulnerable. This, however, is
      an overstatement as a well-designed application should never fully
      rely on TCP in achieving end-to-end reliability at the application
      level. First, current APIs to TCP, such as the Berkeley socket
      interface, do not allow applications to know when an TCP
      acknowledgement for previously sent user data arrives at TCP
      sender.  Second, even if the application is informed of the TCP
      acknowledgements, the sending application cannot know whether the
      receiving application has received the data: it only knows that
      the data reached the TCP receive buffer at the receiving end.
      Finally, in order to achieve end-to-end reliability at the
      application level an application level acknowledgement is required
      to confirm that the receiver has taken the appropriate actions on
      the data it received.

   -  When a mobile device moves, it is subject to handovers by the
      serving base station. If the base station acts as the intermediate
      node for the split TCP connection, the state of both TCP endpoints
      on the previous intermediate node must be transferred to the new
      intermediate node to ensure continued operation over the split TCP
      connection. This requires extra work and causes overhead. However,
      in most of the W-WAN wireless networks, unlike in W-LANs, the W-
      WAN base station does not provide the mobile device with the
      connection point to the wireline Internet (such base stations may
      not even have an IP stack).  Instead, the W-WAN network takes care
      of the mobility and retains the connection point to the wireline
      Internet unchanged while the mobile device moves.  Thus, TCP state
      handover is not required in most W-WANs.

   -  The packets traversing through all the protocol layers up to
      transport layer and again down to the link layer result in extra
      overhead at the intermediate node. In case of LTNs with low



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


      bandwidth, this extra overhead does not cause serious additional
      performance problems unlike with W-LANs that typically have much
      higher bandwidth.

   -  Split TCP proposals are not applicable to networks with asymmetric
      routing. Deploying a split TCP approach requires that traffic to
      and from the mobile device be routed through the intermediate
      node. With some networks, this cannot be accomplished, or it
      requires that the intermediate node is located several hops away
      from the wireless network edge which in turn is unpractical in
      many cases and may result in non-optimal routing.

   -  Split TCP, as the name implies, does not address problems related
      to UDP.

   It should noted that using split TCP does not necessarily exclude
   simultaneous usage of IP for end-to-end connectivity.  Correct usage
   of split TCP should be managed per application or per connection and
   should be under the end-user control so that the user can decide
   whether a particular TCP connection or application makes use of split
   TCP or whether it operates end-to-end directly over IP.

   Recommendation: Split TCP proposals that alter TCP semantics are not
   recommended. Deploying custom protocols on the wireless link, such as
   MOWGLI proposes is not recommended, because this note gives
   preference to (1) improving TCP instead of designing a custom
   protocol and (2) allowing end-to-end sessions at all times.

4.10.2 Application Level Proxies

   Nowadays, application level proxies are widely used in the Internet.
   Such proxies include