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.
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
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
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.
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);
- 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.
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
- 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.
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
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
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
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.
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.
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
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.
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", RFC2757 "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.
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.
[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.
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5,
RFC792, 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, RFC1122, October 1989.
[RFC1144] Jacobson, V., "Compressing TCP/IP Headers for Low-Speed
Serial Links", RFC1144, February 1990.
[RFC1323] Jacobson, V., Braden, R. and D. Borman, "TCP Extensions
for High Performance", RFC1323, May 1992.
[RFC1958] Carpenter, B., "Architectural Principles of the
Internet", RFC1958, June 1996.
[RFC2018] Mathis, M., Mahdavi, J., Floyd, S. and A. Romanow, "TCP
Selective Acknowledgment Options", RFC2018, October
1996.
[RFC2151] Kessler, G. and S. Shepard, "A Primer On Internet and
TCP/IP Tools and Utilities", FYI 30, RFC2151, 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)", RFC2393,
December 1998.
[RFC2401] Kent, S., and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC2401, November 1998.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.
and W. Weiss, "An Architecture for Differentiated
Services", RFC2475, December 1998.
[RFC2488] Allman, M., Glover, D. and L. Sanchez, "Enhancing TCP
Over Satellite Channels using Standard Mechanisms", BCP
28, RFC2488, January 1999.
[RFC2507] Degermark, M., Nordgren, B. and S. Pink, "IP Header
Compression", RFC2507, February 1999.
[RFC2508] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP
Headers for Low-Speed Serial Links", RFC2508, February
1999.
[RFC2509] Engan, M., Casner, S. and C. Bormann, "IP Header
Compression over PPP", RFC2509, February 1999.
[RFC2663] Srisuresh, P. and Y. Holdrege, "IP Network Address