Tech-invite3GPPspaceIETFspace
96959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 3135

Performance Enhancing Proxies Intended to Mitigate Link-Related Degradations

Pages: 45
Informational
Part 2 of 2 – Pages 21 to 45
First   Prev   None

Top   ToC   RFC3135 - Page 21   prevText

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
Top   ToC   RFC3135 - Page 22
   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.
Top   ToC   RFC3135 - Page 23
      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; - They support some form of compression to reduce the amount of bandwidth required (with emphasis on saving inroute bandwidth). The key differentiators between VSAT network PEP implementations are: - The maximum throughput they attempt to support (mainly a function of the amount of buffer space they use);
Top   ToC   RFC3135 - Page 24
      - The protocol used over the satellite link.  Some implementations
        use a modified version of TCP while others use a proprietary
        protocol running on top of UDP;

      - The type of compression used.  Third party VSAT network PEP
        implementations generally focus on application (e.g., HTTP)
        specific compression algorithms while PEP implementations
        integrated into the VSAT network generally focus on link
        specific compression.

   PEP implementations integrated into a VSAT product are generally
   transparent to the end systems.  Third party PEP implementations used
   with VSAT networks usually require configuration changes in the
   remote site end systems to route TCP packets to the remote site
   proxies but do not require changes to the hub site end systems.  In
   some cases, the PEP implementation is actually integrated
   transparently into the end system node itself, using a "bump in the
   stack" approach.  In all cases, the use of a PEP is non-transparent
   to the user, i.e., the user is aware when a PEP implementation is
   being used to boost performance.

5.1.3 VSAT Network PEP Motivation

VSAT networks, since the early stages of their deployment, have supported the use of local termination of a protocol (e.g., SDLC and X.25) on each side of the satellite link to hide the satellite link from the applications using the protocol. Therefore, when LAN capabilities were added to VSAT networks, VSAT customers expected and, in fact, demanded, the use of similar techniques for improving the performance of IP based traffic, in particular TCP traffic. As indicated in Section 5.1, VSAT networks are primarily used to implement intranets with Internet connectivity limited to and closely controlled at the hub site of the VSAT network. Therefore, VSAT customers are not as affected (or at least perceive that they are not as affected) by the Internet related implications of using PEPs as are other technologies. Instead, what is more important to VSAT customers is the optimization of the network. And, VSAT customers, in general, prefer that the optimization of the network be done by the network itself rather than by implementing changes (such as enabling the TCP scaled window option) to their own equipment. VSAT customers prefer to optimize their end system configuration for local communications related to their local mission critical functions and let the VSAT network hide the presence of the satellite link as much as possible. VSAT network vendors have also been able to use PEP functionality to provide value added "services" to their customers such as extending the useful of life of older equipment which includes older, "non-modern" TCP stacks.
Top   ToC   RFC3135 - Page 25
   Of course, as the line between intranets and the Internet continues
   to fade, the implications of using PEPs start to become more
   significant for VSAT networks.  For example, twelve years ago
   security was not a major concern because the equipment cost related
   to being able to intercept VSAT traffic was relatively high.  Now, as
   technology has advanced, the cost is much less prohibitive.
   Therefore, because the use of PEP functionality in VSAT networks
   prevents the use of IPsec, customers must rely on the use of higher
   layer security mechanisms such as TLS or on proprietary security
   mechanisms implemented in the VSAT networks themselves (since
   currently many applications are incapable of making (or simply don't
   make) use of the standardized higher layer security mechanisms).
   This, in turn, affects the cost of the VSAT network as well as
   affects the ability of the customers to make use of Internet based
   capabilities.

5.2 W-WAN Environments

In mobile wireless WAN (W-WAN) environments the wireless link is typically used as the last-hop link to the end user. W-WANs include such networks as GSM [GSM], GPRS [GPRS],[BW97], CDPD [CDPD], IS-95 [CDMA], RichoNet, and PHS. Many of these networks, but not all, have been designed to provide mobile telephone voice service in the first place but include data services as well or they evolve from a mobile telephone network.

5.2.1 W-WAN Network Characteristics

W-WAN links typically exhibit some combination of the following link characteristics: - low bandwidth (with some links the available bandwidth might be as low as a few hundred bits/sec) - high latency (minimum round-trip delay close to one second is not exceptional) - high BER resulting in frame or packet losses, or long variable delays due to local link-layer error recovery - some W-WAN links have a lot of internal buffer space which tend to accumulate data, thus resulting in increased round-trip delay due to long (and variable) queuing delays - on some W-WAN links the users may share common channels for their data packet delivery which, in turn, may cause unexpected delays to the packet delivery of a user due to simultaneous use of the same channel resources by the other users
Top   ToC   RFC3135 - Page 26
      -  unexpected link disconnections (or intermittent link outages)
         may occur frequently and the period of disconnection may last a
         very long time

      -  (re)setting the link-connection up may take a long time
         (several tens of seconds or even minutes)

      -  the W-WAN network typically takes care of terminal mobility:
         the connection point to the Internet is retained while the user
         moves with the mobile host

      -  the use of most W-WAN links is expensive.  Many of the service
         providers apply time-based charging.

5.2.2 W-WAN PEP Implementations

Performance Enhancing Proxies implemented for W-WAN environments generally focus on improving the interactive response time but at the same time aim at improving throughput, mainly by reducing the transfer volume over the inherently slow link in various ways. To achieve this, typically enhancements are applied at almost all protocol layers.
5.2.2.1 Mowgli System
The Mowgli system [KRA94] is one of the early approaches to address the challenges induced by the problematic characteristics of low bandwidth W-WAN links. The indirect approach used in Mowgli is not limited to a single layer as in many other split connection approaches, but it involves all protocol layers. The basic architecture is based on split TCP (UDP is also supported) together with full support for application layer proxies with a distributed PEP approach. An application layer proxy pair may be added between a client and server, the agent (local proxy) on a mobile host and the proxy on an intermediate node that provides the mobile host with the connection to the wireline Internet. Such a pair may be either explicit or fully transparent to the applications, but it is, at all times, under end-user control thus allowing the user to select the traffic that traverses through the PEP implementation and choose end-to-end IP for other traffic. In order to allow running legacy applications unmodified and without recompilation, the socket layer implementation on the mobile host is slightly modified to connect the applications, which are configured to traverse through the PEP, to a local agent while retaining the original TCP/IP socket semantics. Two types of application layer agent-proxy pairs can be configured for mobile host application use.
Top   ToC   RFC3135 - Page 27
   A generic pair can be used with any application and it simply
   provides split transport service with some optional generic
   enhancements like compression.  An application-specific pair can be
   retailed for any application or a group of applications that are able
   to take leverage on the same kind of enhancements.  A good example of
   enhancements achieved with an application-specific proxy pair is the
   Mowgli WWW system that improves significantly the user perceived
   response time of Web browsing mainly by reducing the transfer volume
   and the number of round trips over the wireless link [LAKLR95],
   [LHKR96].

   Mowgli provides also an option to replace the TCP/IP core protocols
   on the last-hop link with a custom protocol that is tuned for low-
   bandwidth W-WAN links [KRLKA97].  This protocol was designed to
   provide the same transport service with similar semantics as regular
   TCP and UDP provide, but use a different protocol implementation that
   can freely apply any appropriate protocol mechanisms without being
   constrained by the current TCP/IP packet format or protocol
   operation.  As this protocol is required to operate over a single
   logical link only, it could partially combine the protocol control
   information and protocol operation of the link, network, and
   transport layers.  In addition, the protocol can operate on top of
   various link services, for example on top of different raw link
   services, on top of PPP, on top of IP, or even on top of a single TCP
   connection using it as a link service and implementing "TCP
   multiplexing" over it.  In all other cases, except when the protocol
   is configured to operate on top of raw (wireless) link service, IP
   may co-exist with the custom protocol allowing simultaneous end-to-
   end IP delivery for the traffic not traversing through the PEP
   implementation.

   Furthermore, the custom protocol can be run in different operation
   modes which turn on or off certain protocol functions depending on
   the underlying link service.  For example, if the underlying link
   service provides reliable data delivery, the checksum and the
   window-based error recovery can be turned off, thus reducing the
   protocol overhead; only a very simple recovery mechanism is needed to
   allow recovery from an unexpected link disconnection.  Therefore, the
   protocol design was able to use extremely efficient header encoding
   (only 1-3 bytes per packet in a typical case), reduce the number of
   round trips significantly, and various features that are useful with
   low-bandwidth W-WAN links were easy to add.  Such features include
   suspending the protocol operation over the periods of link
   disconnection or link outage together with fast start once the link
   becomes operational again, priority-based multiplexing of user data
   over the W-WAN link thus offering link capacity to interactive
Top   ToC   RFC3135 - Page 28
   applications in a timely manner even in presence of bandwidth-
   intensive background transfers, and link-level flow control to
   prevent data from accumulating into the W-WAN link internal buffers.

   If desired, regular TCP/IP transport, possibly with corresponding
   protocol modifications in TCP (and UDP) that would tune it more
   suitable for W-WAN links, can be employed on the last-hop link.

5.2.2.2 Wireless Application Protocol (WAP)
The Mowgli system was designed to support mobile hosts that are attached to the Internet over constrained links, but did not address the specific challenges with low-end mobile devices. Many mobile wireless devices are power, memory, and processing constrained, and the communication links to these devices have lower bandwidth and less stable connections. These limitations led designers to develop the Wireless Application Protocol (WAP) that specifies an application framework and network protocols intended to work across differing narrowband wireless network technologies bringing Internet content and advanced data services to low-end digital cellular phones and other mobile wireless terminals, such as pagers and PDAs. The WAP model consists of a WAP client (mobile terminal), a WAP proxy, and an origin server. It requires a WAP proxy between the WAP client and the server on the Internet. WAP uses a layered, scalable architecture [WAPARCH], specifying the following five protocol layers to be used between the terminal and the proxy: Application Layer (WAE) [WAPWAE], Session Layer (WSP) [WAPWSP], Transaction Layer (WTP) [WAPWTP], Security Layer (WTLS) [WAPWTLS], and Transport Layer (WDP) [WAPWDP]. Standard Internet protocols are used between the proxy and the origin server. If the origin server includes WAP proxy functionality, it is called a WAP Server. In a typical scenario, a WAP client sends an encoded WAP request to a WAP proxy. The WAP proxy translates the WAP request into a WWW (HTTP) request, performing the required protocol conversions, and submits this request to a standard web server on the Internet. After the web server responds to the WAP proxy, the response is encoded into a more compact binary format to decrease the size of the data over the air. This encoded response is forwarded to the WAP client [WAPPROXY]. WAP operates over a variety of bearer datagram services. When communicating over these bearer services, the WAP transport layer (WDP) is always used between the WAP client and WAP proxy and it provides port addressed datagram service to the higher WAP layers. If the bearer service supports IP (e.g., GSM-CSD, GSM-GPRS, IS-136, CDPD), UDP is used as the datagram protocol. However, if the bearer
Top   ToC   RFC3135 - Page 29
   service does not support IP (e.g., GSM-SMS, GSM-USSD, GSM Cell
   Broadcast, CDMS-SMS, TETRA-SDS), WDP implements the required datagram
   protocol as an adaptation layer between the bearer network and the
   protocol stack.

   The use of the other layers depends on the port number.  WAP has
   registered a set of well-known ports with IANA.  The port number
   selected by the application for communication between a WAP client
   and proxy defines the other layers to be used at each end.  The
   security layer, WTLS, provides privacy, data integrity and
   authentication.  Its functionality is similar to TLS 1.0 [RFC2246]
   extended with datagram support, optimized handshake and dynamic key
   refreshing.  If the origin server includes WAP proxy functionality,
   it might be used to facilitate the end-to-end security solutions,
   otherwise it provides security between the mobile terminal and the
   proxy.

   The transaction layer, WTP, is message based without connection
   establishment and tear down.  It supports three types of transaction
   classes: an unconfirmed request (unidirectional), a reliable
   (confirmed) request (unidirectional), and a reliable (confirmed)
   request-reply transaction.  Data is carried in the first packet and
   3-way handshake is eliminated to reduce latencies.  In addition
   acknowledgments, retransmission, and flow control are provided.  It
   allows more than one outstanding transaction at a time.  It handles
   the bearer dependence of a transfer, e.g., selects timeout values and
   packet sizes according to the bearer.  Unfortunately, WTP uses fixed
   retransmission timers and does not include congestion control, which
   is a potential problem area as the use of WAP increases [RFC3002].

   The session layer, WSP, supports binary encoded HTTP 1.1 with some
   extensions such as long living session with suspend/resume facility
   and state handling, header caching, and push facility.  On top of the
   architecture is the application environment (WAE).

5.2.3 W-WAN PEP Motivation

As indicated in Section 5.2.1, W-WAN networks typically offer very low bandwidth connections with high latency and relatively frequent periods of link disconnection and they usually are expensive to use. Therefore, the transfer volume and extra round-trips, such as those associated with TCP connection setup and teardown, must be reduced and the slow W-WAN link should be efficiently shielded from excess traffic and global (wired) Internet congestion to make Internet access usable and economical. Furthermore, interactive traffic must be transmitted in a timely manner even if there are other simultaneous bandwidth intensive (background) transfers and during the periods with connectivity the link must be kept fully utilized
Top   ToC   RFC3135 - Page 30
   due to expensive use.  In addition, the (long) periods of link
   disconnection must not abort active (bulk data) transfers, if an
   end-user so desires.

   As (all) applications cannot be made mobility/W-WAN aware in short
   time frame or maybe ever, support for mobile W-WAN use should be
   implemented in a way which allows most applications, at least those
   running on fixed Internet hosts, to continue their operation
   unmodified.

5.3 W-LAN Environments

Wireless LANs (W-LAN) are typically organized in a cellular topology where an access point with a W-LAN transceiver controls a single cell. A cell is defined in terms of the coverage area of the base station. The access points are directly connected to the wired network. The access point in each of the cells is responsible for forwarding packets to and from the hosts located in the cell. Often the hosts with W-LAN transceivers are mobile. When such a mobile host moves from one cell to another cell, the responsibility for forwarding packets between the wired network and the mobile host must be transferred to the access point of the new cell. This is known as a handoff. Many W-LAN systems also support an operation mode enabling ad-hoc networking. In this mode access points are not necessarily needed, but hosts with W-LAN transceiver can communicate directly with the other hosts within the transceiver's transmission range.

5.3.1 W-LAN Network Characteristics

Current wireless LANs typically provide link bandwidth from 1 Mbps to 11 Mbps. In the future, wide deployment of higher bandwidths up to 54 Mbps or even higher can be expected. The round-trip delay with wireless LANs is on the order of a few milliseconds or tens of milliseconds. Examples of W-LANs include IEEE 802.11, HomeRF, and Hiperlan. Wireless personal area networks (WPAN) such as Bluethooth can use the same PEP techniques. Wireless LANs are error-prone due to bit errors, collisions and link outages. In addition, consecutive packet losses may also occur during handoffs. Most W-LAN MAC protocols perform low level retransmissions. This feature shields upper layers from most losses. However, unavoidable losses, retransmission latency and link outages still affect upper layers. TCP performance over W-LANs or a network path involving a W-LAN link is likely to suffer from these effects.
Top   ToC   RFC3135 - Page 31
   As TCP wrongly interprets these packet losses to be network
   congestion, the TCP sender reduces its congestion window and is often
   forced to timeout in order to recover from the consecutive losses.
   The result is often unacceptably poor end-to-end performance.

5.3.2 W-LAN PEP Implementations: Snoop

Berkeley's Snoop protocol [SNOOP] is a TCP-specific approach in which a TCP-aware module, a Snoop agent, is deployed at the W-LAN base station that acts as the last-hop router to the mobile host. Snoop aims at retaining the TCP end-to-end semantics. The Snoop agent monitors every packet that passes through the base station in either direction and maintains soft state for each TCP connection. The Snoop agent is an asymmetric PEP implementation as it operates differently on TCP data and ACK channels as well as on the uplink (from the mobile host) and downlink (to the mobile host) TCP segments. For a data transfer to a mobile host, the Snoop agent caches unacknowledged TCP data segments which it forwards to the TCP receiver and monitors the corresponding ACKs. It does two things: 1. Retransmits any lost data segments locally by using local timers and TCP duplicate ACKs to identify packet loss, instead of waiting for the TCP sender to do so end-to-end. 2. Suppresses the duplicate ACKs on their way from the mobile host back to the sender, thus avoiding fast retransmit and congestion avoidance at the latter. Suppressing the duplicate ACKs is required to avoid unnecessary fast retransmits by the TCP sender as the Snoop agent retransmits a packet locally. Consider a system that employs the Snoop agent and a TCP sender S that sends packets to receiver R via a base station BS. Assume that S sends packets A, B, C, D, E (in that order) which are forwarded by BS to the wireless receiver R. Assume the first transmission of packet B is lost due to errors on the wireless link. In this case, R receives packets A, C, D, E and B (in that order). Receipt of packets C, D and E trigger duplicate ACKs. When S receives three duplicate ACKs, it triggers fast retransmit (which results in a retransmission, as well as reduction of the congestion window). The Snoop agent also retransmits B locally, when it receives three duplicate ACKs. The fast retransmit at S occurs despite the local retransmit on the wireless link, degrading throughput. Snoop deals with this problem by dropping TCP duplicate ACKs appropriately at BS.
Top   ToC   RFC3135 - Page 32
   For a data transfer from a mobile host, the Snoop agent detects the
   packet losses on the wireless link by monitoring the data segments it
   forwards.  It then employs either Negative Acknowledgements (NAK)
   locally or Explicit Loss Notifications (ELN) to inform the mobile
   sender that the packet loss was not related to congestion, thus
   allowing the sender to retransmit without triggering normal
   congestion control procedures.  To implement this, changes at the
   mobile host are required.

   When a Snoop agent uses NAKs to inform the TCP sender of the packet
   losses on the wireless link, one possibility to implement them is
   using the Selective Acknowledgment (SACK) option of TCP [RFC2018].
   This requires enabling SACK processing at the mobile host.  The Snoop
   agent sends a TCP SACK, when it detects a hole in the transmission
   sequence from the mobile host or when it has not received any new
   packets from the mobile host for a certain time period.  This
   approach relies on the advisory nature of the SACKs: the mobile
   sender is advised to retransmit the missing segments indicated by
   SACK, but it must not assume successful end-to-end delivery of the
   segments acknowledged with SACK as these segments might get lost
   later in the path to the receiver.  Instead, the sender must wait for
   a cumulative ACK to arrive.

   When the ELN mechanism is used to inform the mobile sender of the
   packet losses, Snoop uses one of the 'unreserved' bits in the TCP
   header for ELN [SNOOPELN].  The Snoop agent keeps track of the holes
   that correspond to segments lost over the wireless link.  When a
   (duplicate) ACK corresponding to a hole in the sequence space arrives
   from the TCP receiver, the Snoop agent sets the ELN bit on the ACK to
   indicate that the loss is unrelated to congestion and then forwards
   the ACK to the TCP sender.  When the sender receives a certain number
   of (duplicate) ACKs with ELN (a configurable variable at the mobile
   host, e.g., two), it retransmit the missing segment without
   performing any congestion control measures.

   The ELN mechanism using one of the six bits reserved for future use
   in the TCP header is dangerous as it exercises checks that might not
   be correctly implemented in TCP stacks, and may expose bugs.

   A scheme such as Snoop is needed only if the possibility of a fast
   retransmit due to wireless errors is non-negligible.  In particular,
   if the wireless link uses link-layer recovery for lost data, then
   this scheme is not beneficial.  Also, if the TCP window tends to stay
   smaller than four segments, for example, due to congestion related
   losses on the wired network, the probability that the Snoop agent
   will have an opportunity to locally retransmit a lost packet is
   small.  This is because at least three duplicate ACKs are needed to
   trigger the local retransmission, but due to small window the Snoop
Top   ToC   RFC3135 - Page 33
   agent may not be able to forward three new packets after the lost
   packet and thus induce the required three duplicate ACKs.
   Conversely, when the TCP window is large enough, Snoop can provide
   significant performance improvement (compared with standard TCP).

   In order to alleviate the problem with small TCP windows, Snoop
   proposes a solution in which a TCP sender is allowed to transmit a
   new data segment for each duplicate ACK it receives as long as the
   number of duplicate ACKs is less than the threshold for TCP fast
   retransmission (three duplicate ACKs).  If the new segment reaches
   the receiver, it will generate another duplicate ACK which, in turn,
   allows the sender to transmit yet another data segment.  This
   continues until enough duplicate ACKs have accumulated to trigger TCP
   fast retransmission.  This proposal is the same as the "Limited
   Transfer" proposal [RFC3042] that has recently been forwarded to the
   standards track.  However, to be able to benefit from this solution,
   it needs to be deployed on TCP senders and therefore it is not ready
   for use in a short time frame.

   Snoop requires the intermediate node (base station) to examine and
   operate on the traffic between the mobile host and the other end host
   on the wired Internet.  Hence, Snoop does not work if the IP traffic
   is encrypted.  Possible solutions involve:

   - making the Snoop agent a party to the security association
     between the client and the server;

   - IPsec tunneling mode, terminated at the Snooping base station.

   However, these techniques require that users trust base stations.

   Snoop also requires that both the data and the corresponding ACKs
   traverse the same base station.  Furthermore, the Snoop agent may
   duplicate efforts by the link layer as it retransmits the TCP data
   segments "at the transport layer" across  the wireless link.  (Snoop
   has been described by its designers as a TCP-aware link layer.  This
   is the right approach: the link and network layers can be much more
   aware of each other than strict layering suggests.)

5.3.3 W-LAN PEP Motivation

Wireless LANs suffer from an error prone wireless channel. Errors can typically be considered bursty and channel conditions may change rapidly from mobility and environmental changes. Packets are dropped from bit errors or during handovers. Periods of link outage can also be experienced. Although the typical MAC performs retransmissions, dropped packets, outages and retransmission latency still can have serious performance implications for IP performance, especially TCP.
Top   ToC   RFC3135 - Page 34
   PEPs can be used to alleviate problems caused by packet losses,
   protect TCP from link outages, and to add priority multiplexing.
   Techniques such as Snoop are integrally implemented in access points,
   while priority and compression schemes are distributed across the W-
   LAN.

6. Security Considerations

The use of Performance Enhancing Proxies introduces several issues which impact security. First, (as described in detail in Section 4.1.1,) using PEPs and using IPsec is generally mutually exclusive. Unless the PEP is also both capable and trusted to be the endpoint of an IPsec tunnel (and the use of an IPsec tunnel is deemed good enough security for the applicable threat model), a user or network administrator must choose between improved performance and network layer security. In some cases, transport (or higher) layer security can be used in conjunction with a PEP to mitigate the impact of not having network layer security. But, support by applications for the use of transport (or higher) layer security is far from ubiquitous. Additionally, the PEP itself needs to be protected from attack. First, even when IPsec tunnels are used with the PEP, the PEP represents a point in the network where traffic is exposed. And, the placement of a PEP in the network makes it an ideal platform from which to launch a denial of service or man in the middle attack. (Also, taking the PEP out of action is a potential denial of service attack itself.) Therefore, the PEP must be protected (e.g., by a firewall) or must protect itself from improper access by an attacker just like any other device which resides in a network.

7. IANA Considerations

This document is an informational overview document and, as such, does not introduce new nor modify existing name or number spaces managed by IANA.

8. Acknowledgements

This document grew out of the Internet-Draft "TCP Performance Enhancing Proxy Terminology", RFC 2757 "Long Thin Networks", and work done in the IETF TCPSAT working group. The authors are indebted to the active members of the PILC working group. In particular, Joe Touch and Mark Allman gave us invaluable feedback on various aspects of the document and Magdolna Gerendai provided us with essential help on the WAP example.
Top   ToC   RFC3135 - Page 35

9. References

[BBKT97] P. Bhagwat, P. Bhattacharya, A. Krishma, S.K. Tripathi, "Using channel state dependent packet scheduling to improve TCP throughput over wireless LANs," ACM Wireless Networks, March 1997, pp. 91 - 102. Available at: http://www.acm.org/pubs /articles/journals/wireless/1997-3-1/p91-bhagwat/p91- bhagwat.pdf [BPK97] H. Balakrishnan, V.N. Padmanabhan, R.H. Katz, "The Effects of Asymmetry on TCP Performance," Proc. ACM/IEEE Mobicom, Budapest, Hungary, September 1997. [BW97] G. Brasche, B. Walke, "Concepts, Services, and Protocols of the New GSM Phase 2+ general Packet Radio Service," IEEE Communications Magazine, Vol. 35, No. 8, August 1997. [CDMA] Electronic Industry Alliance (EIA)/Telecommunications Industry Association (TIA), IS-95: Mobile Station-Base Station Compatibility Standard for Dual-Mode Wideband Spread Spectrum Cellular System, 1993. [CDPD] Wireless Data Forum, CDPD System Specification, Release 1.1, 1995. [CTC+97] H. Chang, C. Tait, N. Cohen, M. Shapiro, S. Mastrianni, R. Floyd, B. Housel, D. Lindquist, "Web Browsing in a Wireless Environment: Disconnected and Asynchronous Operation in ARTour Web Express," Proc. MobiCom'97, Budapest, Hungary, September 1997. [FMSBMR98] D.C. Feldmeier, A.J. McAuley, J.M. Smith, D.S. Bakin, W.S. Marcus, T.M. Raleigh, "Protocol Boosters," IEEE Journal on Selected Areas of Communication, Vol. 16, No. 3, April 1998. [FLASH] Flash Networks Ltd., performance boosting products technology vendor based in Holmdel, New Jersey. Website at http://www.flashnetworks.com. [FOURELLE] Fourelle Systems, performance boosting products technology vendor based in Santa Clara, California. Website at http://www.fourelle.com. [GPRS] ETSI, "General Packet Radio Service (GPRS): Service Description, Stage 2," GSM03.60, v.6.1.1, August 1998.
Top   ToC   RFC3135 - Page 36
   [GSM]       M. Rahnema, "Overview of the GSM system and protocol
               architecture," IEEE Communications Magazine, Vol. 31, No.
               4, pp. 92-100, April 1993.

   [HNS]       Hughes Network Systems, Inc., VSAT technology vendor
               based in Germantown, Maryland.  Website at
               http://www.hns.com.

   [I-TCP]     A. Bakre, B.R. Badrinath, "I-TCP: Indirect TCP for Mobile
               Hosts," Proc. 15th International Conference on
               Distributed Computing Systems (ICDCS), May 1995.

   [KRA94]     M. Kojo, K. Raatikainen, T. Alanko, "Connecting Mobile
               Workstations to the Internet over a Digital Cellular
               Telephone Network," Proc. Workshop on Mobile and Wireless
               Information Systems (MOBIDATA), Rutgers University, NJ,
               November 1994.  Revised version published in Mobile
               Computing, pp. 253-270, Kluwer, 1996.

   [KRLKA97]   M. Kojo, K. Raatikainen, M. Liljeberg, J. Kiiskinen, T.
               Alanko, "An Efficient Transport Service for Slow Wireless
               Telephone Links," IEEE Journal on Selected Areas of
               Communication, Vol. 15, No. 7, September 1997.

   [LAKLR95]   M. Liljeberg, T. Alanko, M. Kojo, H. Laamanen, K.
               Raatikainen, "Optimizing World-Wide Web for Weakly-
               Connected Mobile Workstations: An Indirect Approach,"
               Proc. of the 2nd Int. Workshop on Services in Distributed
               and Networked Environments, Whistler, Canada, pp. 132-
               139, June 1995.

   [LHKR96]    M. Liljeberg, H. Helin, M. Kojo, K. Raatikainen, "Mowgli
               WWW Software: Improved Usability of WWW in Mobile WAN
               Environments," Proc. IEEE Global Internet 1996
               Conference, London, UK, November 1996.

   [M-TCP]     K. Brown, S. Singh, "M-TCP: TCP for Mobile Cellular
               Networks," ACM Computer Communications Review Volume
               27(5), 1997.  Available at
               ftp://ftp.ece.orst.edu/pub/singh/papers/mtcp.ps.gz.

   [Pax99]     V. Paxson, "End-to-End Internet Packet Dynamics,"
               IEEE/ACM Transactions on Networking, Vol. 7, No. 3, 1999,
               pp. 277-292.

   [PILCWEB]   http://pilc.grc.nasa.gov.
Top   ToC   RFC3135 - Page 37
   [RFC0792]   Postel, J., "Internet Control Message Protocol", STD 5,
               RFC 792, September 1981.

   [RFC0793]   Postel, J., "Transmission Control Protocol", STD 7, RFC
               793, September 1981.

   [RFC1122]   Braden, R., "Requirements for Internet Hosts --
               Communications Layers", STD 3, RFC 1122, October 1989.

   [RFC1144]   Jacobson, V., "Compressing TCP/IP Headers for Low-Speed
               Serial Links", RFC 1144, February 1990.

   [RFC1323]   Jacobson, V., Braden, R. and D. Borman, "TCP Extensions
               for High Performance", RFC 1323, May 1992.

   [RFC1958]   Carpenter, B., "Architectural Principles of the
               Internet", RFC 1958, June 1996.

   [RFC2018]   Mathis, M., Mahdavi, J., Floyd, S. and A. Romanow, "TCP
               Selective Acknowledgment Options", RFC 2018, October
               1996.

   [RFC2151]   Kessler, G. and S. Shepard, "A Primer On Internet and
               TCP/IP Tools and Utilities", FYI 30, RFC 2151, June 1997.

   [RFC2246]   Dierk, T. and E. Allen, "TLS Protocol Version 1," RFC
               2246, January 1999.

   [RFC2393]   Shacham, A., Monsour, R., Pereira, R. and M. Thomas, "IP
               Payload Compression Protocol (IPcomp)", RFC 2393,
               December 1998.

   [RFC2401]   Kent, S., and R. Atkinson, "Security Architecture for the
               Internet Protocol", RFC 2401, November 1998.

   [RFC2475]   Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.
               and W. Weiss, "An Architecture for Differentiated
               Services", RFC 2475, December 1998.

   [RFC2488]   Allman, M., Glover, D. and L. Sanchez, "Enhancing TCP
               Over Satellite Channels using Standard Mechanisms", BCP
               28, RFC 2488, January 1999.

   [RFC2507]   Degermark, M., Nordgren, B. and S. Pink, "IP Header
               Compression", RFC 2507, February 1999.
Top   ToC   RFC3135 - Page 38
   [RFC2508]   Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP
               Headers for Low-Speed Serial Links", RFC 2508, February
               1999.

   [RFC2509]   Engan, M., Casner, S. and C. Bormann, "IP Header
               Compression over PPP", RFC 2509, February 1999.

   [RFC2663]   Srisuresh, P. and Y. Holdrege, "IP Network Address
               Translator (NAT) Terminology and Considerations", RFC
               2663, August 1999.

   [RFC2760]   Allman, M., Dawkins, S., Glover, D., Griner, J.,
               Henderson, T., Heidemann, J., Kruse, H., Ostermann, S.,
               Scott, K., Semke, J., Touch, J. and D. Tran, "Ongoing TCP
               Research Related to Satellites", RFC 2760, February 2000.

   [RFC3002]   Mitzel, D., "Overview of 2000 IAB Wireless
               Internetworking Workshop", RFC 3002, December 2000.

   [RFC3042]   Allman, M., Balakrishnan, H. and S. Floyd, "Enhancing
               TCP's Loss Recovery Using Limited Transmit", RFC 3042,
               January 2001.

   [SHEL00]    Z. Shelby, T. Saarinen, P. Mahonen, D. Melpignano, A.
               Marshall, L. Munoz, "Wireless IPv6 Networks - WINE," IST
               Mobile Summit, Ireland, October 2000.

   [SNOOP]     H. Balakrishnan, S. Seshan, E. Amir, R. Katz, "Improving
               TCP/IP Performance over Wireless Networks," Proc. 1st ACM
               Conference on Mobile Communications and Networking
               (Mobicom), Berkeley, California, November 1995.

   [SNOOPELN]  H. Balakrishnan, R. Katz, "Explicit Loss Notification and
               Wireless Web Performance," Proc. IEEE Globecom 1998,
               Internet Mini-Conference, Sydney, Australia, November
               1998.

   [SPACENET]  Spacenet, VSAT technology vendor based in Mclean,
               Virginia.  Website at http://www.spacenet.com.

   [SRC84]     J.H. Saltzer, D.P. Reed, D.D. Clark, "End-To-End
               Arguments in System Design," ACM TOCS, Vol. 2, No. 4, pp.
               277-288, November 1984.

   [WAPARCH]   Wireless Application Protocol Architecture Specification,
               April 1998, http://www.wapforum.org.
Top   ToC   RFC3135 - Page 39
   [WAPPROXY]  Wireless Application Protocol Push Proxy Gateway Service
               Specification, August 1999, http://www.wapforum.org.

   [WAPWAE]    Wireless Application Protocol Wireless Application
               Environment Overview, March 2000,
               http://www.wapforum.org.

   [WAPWDP]    Wireless Application Protocol Wireless Datagram Protocol
               Specification, February 2000, http://www.wapforum.org.

   [WAPWSP]    Wireless Application Protocol Wireless Session Protocol
               Specification, May 2000, http://www.wapforum.org.

   [WAPWTLS]   Wireless Application Protocol Wireless Transport Layer
               Security Specification, February 2000,
               http://www.wapforum.org.

   [WAPWTP]    Wireless Application Protocol Wireless Transaction
               Protocol Specification, February 2000,
               http://www.wapforum.org.

   [Zhang00]   Y. Zhang, B. Singh, "A Multi-Layer IPsec Protocol," Proc.
               proceedings of 9th USENIX Security Symposium, Denver,
               Colorado, August 2000.  Available at
               http://www.wins.hrl.com/people/ygz/papers/usenix00.html.

10. Authors' Addresses

Questions about this document may be directed to: John Border Hughes Network Systems 11717 Exploration Lane Germantown, Maryland 20876 Phone: +1-301-548-6819 Fax: +1-301-548-1196 EMail: border@hns.com
Top   ToC   RFC3135 - Page 40
   Markku Kojo
   Department of Computer Science
   University of Helsinki
   P.O. Box 26 (Teollisuuskatu 23)
   FIN-00014 HELSINKI
   Finland

   Phone: +358-9-1914-4179
   Fax:   +358-9-1914-4441
   EMail: kojo@cs.helsinki.fi


   Jim Griner
   NASA Glenn Research Center
   MS: 54-5
   21000 Brookpark Orad
   Cleveland, Ohio  44135-3191

   Phone: +1-216-433-5787
   Fax:   +1-216-433-8705
   EMail: jgriner@grc.nasa.gov


   Gabriel Montenegro
   Sun Microsystems Laboratories, Europe
   29, chemin du Vieux Chene
   38240 Meylan, FRANCE

   Phone: +33 476 18 80 45
   EMail: gab@sun.com


   Zach Shelby
   University of Oulu
   Center for Wireless Communications
   PO Box 4500
   FIN-90014
   Finland

   Phone: +358-40-779-6297
   EMail: zach.shelby@ee.oulu.fi
Top   ToC   RFC3135 - Page 41

Appendix A - PEP Terminology Summary

This appendix provides a summary of terminology frequently used during discussion of Performance Enhancing Proxies. (In some cases, these terms have different meanings from their non-PEP related usage.) ACK filtering Removing acknowledgments to prevent congestion of a low speed link, usually used with paths which include a highly asymmetric link. Sometimes also called ACK reduction. See Section 3.1.4. ACK spacing Delayed forwarding of acknowledgments in order to space them appropriately, for example, to help minimize the burstiness of TCP data. See Section 3.1.1. application layer PEP A Performance Enhancing Proxy operating above the transport layer. May be aimed at improving application or transport protocol performance (or both). Described in detail in Section 2.1.2. asymmetric link A link which has different rates for the forward channel (used for data segments) and the back (or return) channel (used for ACKs). available bandwidth The total capacity of a link available to carry information at any given time. May be lower than the raw bandwidth due to competing traffic. bandwidth utilization The actual amount of information delivered over a link in a given period, usually expressed as a percent of the raw bandwidth of the link. gateway Has several meanings with respect to PEPs, depending on context: - An access point to a particular link;
Top   ToC   RFC3135 - Page 42
         -  A device capable of initiating and terminating connections
            on

            behalf of a user or end system (e.g., a firewall or proxy).

      Not necessarily, but could be, a router.

   in flight (data)

      Data sent but not yet acknowledged.  More precisely, data sent for
      which the sender has not yet received the acknowledgement.

   link layer PEP

      A Performance Enhancing Proxy operating below the network layer.

   local acknowledgement

      The generation of acknowledgments by an entity in the path
      between two end systems in order to allow the sending system to
      transmit more data without waiting for end-to-end
      acknowledgments.  Described (in the context of TCP) in Section
      3.1.2.

   performance enhancing proxy

      An entity in the network acting on behalf of an end system or user
      (with or without the knowledge of the end system or user) in order
      to enhance protocol performance.  Section 2 describes various
      types of performance enhancing proxies.  Section 3 describes the
      mechanisms performance enhancing proxies use to improve
      performance.

   raw bandwidth

      The total capacity of an unloaded link available to carry
      information.

   Snoop

      A TCP-aware link layer developed for wireless packet radio and
      cellular networks.  It works by caching segments at a wireless
      base station.  If the base station sees duplicate acknowledgments
      for a segment that it has cached, it retransmits the missing
      segment while suppressing the duplicate acknowledgement stream
      being forwarded back to the sender until the wireless receiver
      starts to acknowledge new data.  Described in detail in Section
      5.3.2 and [SNOOP].
Top   ToC   RFC3135 - Page 43
   split connection

      A connection that has been terminated before reaching the intended
      destination end system in order to initiate another connection
      towards the end system.  This allows the use of different
      connection characteristics for different parts of the path of
      the originally intended connection.  See Section 2.4.

   TCP PEP

      A Performance Enhancing Proxy operating at the transport layer
      with TCP.  Aimed at improving TCP performance.

   TCP splitting

      Using one or more split TCP connections to improve TCP
      performance.

   TCP spoofing

      Sometimes used as a synonym for TCP PEP.  More accurately, TCP
      spoofing refers to using transparent (to the TCP stacks in the
      end systems) mechanisms to improve TCP performance.  See Section
      2.1.1.

   transparent

      In the context of a PEP, transparent refers to not requiring
      changes to be made to the end systems, transport endpoints
      and/or applications involved in a connection.  See Section 2.5
      for a more detailed explanation.

   transport layer PEP

      A Performance Enhancing Proxy operating at the transport layer.
      Described in detail in Section 2.1.1.

   tunneling

      In the context of PEPs, tunneling refers to the process of
      wrapping a packet for transmission over a particular link
      between two PEPs.  See Section 3.2.
Top   ToC   RFC3135 - Page 44
   WAP

      The Wireless Application Protocol specifies an application
      framework and network protocols intended to work across
      differing narrow-band wireless network technologies.  See
      Section 5.2.2.2.
Top   ToC   RFC3135 - Page 45
Full Copyright Statement

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.