rfc3135.txt

RFC 的详细文档！

   implications of delayed detection of a failed connection depend on
   the applications being used.  Possibilities range from no impact at
   all (or just minor annoyance to the end user) all the way up to
   impacting mission critical business functions by delaying switchovers
   to alternate communications paths.

   In addition, tools used to debug connection failures may be affected
   by the use of a PEP.  For example, PING (described in [RFC792] and
   [RFC2151]) is often used to test for connectivity.  But, because PING
   is based on ICMP instead of TCP (i.e., it is implemented using ICMP
   Echo and Reply commands at the network layer), it is possible that
   the configuration of the network might route PING traffic around the
   PEP.  Thus, PING could indicate that an end-to-end path exists
   between two hosts when it does not actually exist for TCP traffic.
   Even when the PING traffic does go through the PEP, the diagnostics
   indications provided by the PING traffic are altered.  For example,
   if the PING traffic goes transparently through the PEP, PING does not
   provide any indication that the PEP exists and since the PING traffic
   is not being subjected to the same processing as TCP traffic, it may
   not necessarily provide an accurate indication of the network delay
   being experienced by TCP traffic.  On the other hand, if the PEP
   terminates the PING and responds to it on behalf of the end host,
   then the PING provides information only on the connectivity to the
   PEP.  Traceroute (also described in [RFC2151]) is similarly affected
   by the presence of the PEP.

4.2 Asymmetric Routing

   Deploying a PEP implementation usually requires that traffic to and
   from the end hosts is routed through the intermediate node(s) where
   PEPs reside.  With some networks, this cannot be accomplished, or it
   might require that the intermediate node is located several hops away
   from the target link edge which in turn is impractical in many cases
   and may result in non-optimal routing.







Border, et al.               Informational                     [Page 19]

RFC 3135          PILC - Performance Enhancing Proxies         June 2001


   Note that this restriction does not apply to all PEP implementations.
   For example, a PEP which is simply doing ACK spacing only needs to
   see one direction of the traffic flow (the direction in which the
   ACKs are flowing).  ACK spacing can be done without seeing the actual
   flow of data.

4.3 Mobile Hosts

   In environments where a PEP implementation is used to serve mobile
   hosts, additional problems may be encountered because PEP related
   state information may need to be transferred to a new PEP node during
   a handoff.

   When a mobile host moves, it is subject to handovers.  If the
   intermediate node and home for the serving PEP changes due to
   handover, any state information that the PEP maintains and is
   required for continuous operation must be transferred to the new
   intermediate node to ensure continued operation of the connection.
   This requires extra work and overhead and may not be possible to
   perform fast enough, especially if the host moves frequently over
   cell boundaries of a wireless network.  If the mobile host moves to
   another IP network, routing to and from the mobile host may need to
   be changed to traverse a new PEP node.

   Today, mobility implications with respect to using PEPs are more
   significant to W-LAN networks than to W-WAN networks.  Currently, a
   W-WAN base station typically does not provide the mobile host with
   the connection point to the wireline Internet.  (A W-WAN base station
   may not even have an IP stack.)  Instead, the W-WAN network takes
   care of mobility with the connection point to the wireline Internet
   remaining unchanged while the mobile host moves.  Thus, PEP state
   handover is not currently required in most W-WAN networks when the
   host moves.  However, this is generally not true in W-LAN networks
   and, even in the case of W-WAN networks, the user and/or network
   administrator using a PEP needs to be cognizant of how the W-WAN base
   stations and the PEP work in case W-WAN PEP state handoff becomes
   necessary in the future.

4.4 Scalability

   Because a PEP typically processes packet information above the IP
   layer, a PEP requires more processing power per packet than a router.
   Therefore, PEPs will always be (at least) one step behind routers in
   terms of the total throughput they can support.  (Processing above
   the IP layer is also more difficult to implement in hardware.)  In
   addition, since most PEP implementations require per connection
   state, PEP memory requirements are generally significantly higher




Border, et al.               Informational                     [Page 20]

RFC 3135          PILC - Performance Enhancing Proxies         June 2001


   than with a router.  Therefore, a PEP implementation may have a limit
   on the number of connections which it can support whereas a router
   has no such limitation.

   Increased processing power and memory requirements introduce
   scalability issues with respect to the use of PEPs.  Placement of a
   PEP on a high speed link or a link which supports a large number of
   connections may require network topology changes beyond just
   inserting the PEP into the path of the traffic.  For example, if a
   PEP can only handle half of the traffic on a link, multiple PEPs may
   need to be used in parallel, adding complexity to the network
   configuration to divide the traffic between the PEPs.

4.5 Other Implications of Using PEPs

   This document describes some significant implications with respect to
   using Performance Enhancing Proxies.  However, the list of
   implications provided in this document is not necessarily exhaustive.
   Some examples of other potential implications related to using PEPs
   include the use of PEPs in multi-homing environments and the use of
   PEPs with respect to Quality of Service (QoS) transparency.  For
   example, there may be potential interaction with the priority-based
   multiplexing mechanism described in Section 3.5 and the use of
   differentiated services [RFC2475].  Therefore, users and network
   administrators who wish to deploy a PEP should look not only at the
   implications described in this document but also at the overall
   impact (positive and negative) that the PEP will have on their
   applications and network infrastructure, both initially and in the
   future when new applications are added and/or changes in the network
   infrastructure are required.

5. PEP Environment Examples

   The following sections describe examples of environments where PEP is
   currently used to improve performance.  The examples are provided to
   illustrate the use of the various PEP types and PEP mechanisms
   described earlier in the document and to help illustrate the
   motivation for their development and use.

5.1 VSAT Environments

   Today, VSAT networks are implemented with geosynchronous satellites.
   VSAT data networks are typically implemented using a star topology.
   A large hub earth station is located at the center of the star with
   VSATs used at the remote sites of the network.  Data is sent from the
   hub to the remote sites via an outroute.  Data is sent from the
   remote sites to the hub via one or more inroutes.  VSATs represent an
   environment with highly asymmetric links, with an outroute typically



Border, et al.               Informational                     [Page 21]

RFC 3135          PILC - Performance Enhancing Proxies         June 2001


   much larger than an inroute.  (Multiple inroutes can be used with
   each outroute but any particular VSAT only has access to a single
   inroute at a time, making the link asymmetric.)

   VSAT networks are generally used to implement private networks (i.e.,
   intranets) for enterprises (e.g., corporations) with geographically
   dispersed sites.  VSAT networks are rarely, if ever, used to
   implement Internet connectivity except at the edge of the Internet
   (i.e., as the last hop).  Connection to the Internet for the VSAT
   network is usually implemented at the VSAT network hub site using
   appropriate firewall and (when necessary) NAT [RFC2663] devices.

5.1.1 VSAT Network Characteristics

   With respect to TCP performance, VSAT networks exhibit the following
   subset of the satellite characteristics documented in [RFC2488]:

   Long feedback loops

      Propagation delay from a sender to a receiver in a geosynchronous
      satellite network can range from 240 to 280 milliseconds,
      depending on where the sending and receiving sites are in the
      satellite footprint.  This makes the round trip time just due to
      propagation delay at least 480 milliseconds.  Queueing delay and
      delay due to shared channel access methods can sometimes increase
      the total delay up to on the order of a few seconds.

   Large bandwidth*delay products

      VSAT networks can support capacity ranging from a few kilobits per
      second up to multiple megabits per second.  When combined with the
      relatively long round trip time, TCP needs to keep a large number
      of packets "in flight" in order to fully utilize the satellite
      link.

   Asymmetric capacity

      As indicated above, the outroute of a VSAT network is usually
      significantly larger than an inroute.  Even though multiple
      inroutes can be used within a network, a given VSAT can only
      access one inroute at a time.  Therefore, the incoming (outroute)
      and outgoing (inroute) capacity for a VSAT is often very
      asymmetric.  As outroute capacity has increased in recent years,
      ratios of 400 to 1 or greater are becoming more and more common.
      With a TCP maximum segment size of 1460 bytes and delayed
      acknowledgments [RFC1122] in use, the ratio of IP packet bytes for
      data to IP packet bytes for ACKs is only (3000 to 40) 75 to 1.




Border, et al.               Informational                     [Page 22]

RFC 3135          PILC - Performance Enhancing Proxies         June 2001


      Thus, inroute capacity for carrying ACKs can have a significant
      impact on TCP performance.  (The issue of asymmetric link impact
      on TCP performance is described in more detail in [BPK97].)

   With respect to the other satellite characteristics listed in
   [RFC2488], VSAT networks typically do not suffer from intermittent
   connectivity or variable round trip times.  Also, VSAT networks
   generally include a significant amount of error correction coding.
   This makes the bit error rate very low during clear sky conditions,
   approaching the bit error rate of a typical terrestrial network.  In
   severe weather, the bit error rate may increase significantly but
   such conditions are rare (when looked at from an overall network
   availability point of view) and VSAT networks are generally
   engineered to work during these conditions but not to optimize
   performance during these conditions.

5.1.2 VSAT Network PEP Implementations

   Performance Enhancing Proxies implemented for VSAT networks generally
   focus on improving throughput (for applications such as FTP and HTTP
   web page retrievals).  To a lesser degree, PEP implementations also
   work to improve interactive response time for small transactions.

   There is not a dominant PEP implementation used with VSAT networks.
   Each VSAT network vendor tends to implement their own version of PEP
   functionality, integrated with the other features of their VSAT
   product.  [HNS] and [SPACENET] describe VSAT products with integrated
   PEP capabilities.  There are also third party PEP implementations
   designed to be used with VSAT networks.  These products run on nodes
   external to the VSAT network at the hub and remote sites.  NettGain
   [FLASH] and Venturi [FOURELLE] are examples of such products.  VSAT
   network PEP implementations generally share the following
   characteristics:

      - They focus on improving TCP performance;

      - They use an asymmetric distributed implementation;

      - They use a split connection approach with local acknowledgments
        and local retransmissions;

      - The