Internet Engineering Task Force J. Border
INTERNET-DRAFT Hughes Network Systems
M. Kojo
University of Helsinki
Jim Griner
NASA Glenn Research Center
G. Montenegro
Sun Microsystems, Inc.
June 25, 1999
Performance Enhancing Proxies
draft-ietf-pilc-pep-00.txt
Status of This Memo
The document is an Internet-Draft and is in full conformance with all
of the provisions of Section 10 of RFC 2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Intenet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Distribution of this draft is unlimited. Comments on this draft
should be sent to the authors or to the PILC mailing list at
pilc@grc.nasa.gov. This draft expires on December 21, 1999.
Abstract
This document provides a high level overview of Performance Enhancing
Proxies. Motivations for their development and use are described as
well as some of the consequences of using them.
Expires December 25, 1999 [Page 1]
INTERNET DRAFT Performance Enhancing Proxies June 1999
Table of Contents
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 Types of Performance Enhancing Proxies . . . . . . . . . . . . . . 4
2.1 Layering . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.1 TCP Performance Enhancing Proxies . . . . . . . . . . . . . . 4
2.1.2 Application Layer Proxies . . . . . . . . . . . . . . . . . . 4
2.2 Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3 Split Connections . . . . . . . . . . . . . . . . . . . . . . . 5
2.4 Transparency . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.5 Tunnelling . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.6 ACK Handling . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.6.1 ACK Spacing . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.6.2 Local Acknowledgements . . . . . . . . . . . . . . . . . . . . 8
2.6.3 Local Retransmissions . . . . . . . . . . . . . . . . . . . . 8
2.7 Compression . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.8 Handling Periods of Link Disconnection . . . . . . . . . . . . . 9
2.9 Other Link Specific Enhancements . . . . . . . . . . . . . . . . 10
3 Implications of Using PEP . . . . . . . . . . . . . . . . . . . . 10
3.1 The End-to-end Argument . . . . . . . . . . . . . . . . . . . . 10
3.1.1 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.1.2 Fate Sharing . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.1.3 End-to-end Acknowledgements . . . . . . . . . . . . . . . . . 12
3.2 Other Implications . . . . . . . . . . . . . . . . . . . . . . . 13
4 PEP Environment Examples . . . . . . . . . . . . . . . . . . . . . 13
4.1 VSAT Environments . . . . . . . . . . . . . . . . . . . . . . . 13
4.1.1 VSAT Network Characteristics . . . . . . . . . . . . . . . . . 13
4.1.2 VSAT Network PEP Implementations . . . . . . . . . . . . . . . 15
4.1.3 VSAT Network PEP Motivation . . . . . . . . . . . . . . . . . 16
4.2 W-WAN Environments . . . . . . . . . . . . . . . . . . . . . . . 16
4.2.1 W-WAN Network Characteristics . . . . . . . . . . . . . . . . 16
4.2.2 W-WAN PEP Implementations . . . . . . . . . . . . . . . . . . 17
4.3 W-LAN Environments . . . . . . . . . . . . . . . . . . . . . . . 17
4.3.1 W-LAN Network Characteristics . . . . . . . . . . . . . . . . 17
4.3.2 W-LAN PEP Implementations: Snoop . . . . . . . . . . . . . . . 18
5 Security Considerations . . . . . . . . . . . . . . . . . . . . . 20
6 Appendix - PEP Terminology Summary . . . . . . . . . . . . . . . . 20
6.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . 21
7 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 23
8 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25
10 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 26
Expires December 25, 1999 [Page 2]
INTERNET DRAFT Performance Enhancing Proxies June 1999
1 Introduction
The Transmission Control Protocol [RFC0793] (TCP) is used as the
transport layer protocol by many Internet and intranet applications.
However, in certain environments, TCP and other higher layer protocol
performance is limited by the link characteristics of the
environment. [Karn99] discusses various link layer design
considerations that should be taken into account when designing a
link layer service that is intended to support the Internet
protocols. Such design choices may have a significant influence on
the performance and efficiency of the Internet. However, not all
link characteristics, for example, high latency, can be compensated
for by such choices in the link design. And, the cost of
compensating for some link characteristics may be prohibitive for
some technologies. A Performance Enhancing Proxy (PEP) is used to
improve the performance of the Internet protocols in environments
where native performance suffers for some reason, usually a
characteristic of the environment.
This document does not intend to advocate use of PEPs in general. On
the contrary, the end-to-end principle in designing Internet
protocols must be retained the prevailing approach and PEPs should be
used only in specific environments and circumstances. In any
environment where one might consider employing PEP for improved
performance, an end user must be aware of the proxy and the choice of
employing PEP must be under the control of the end user at all
times. This also means that the end user must always be able to
choose end-to-end IP service.
The remainder of this document is organized as follows. Section 2
provides an overview of different kinds of PEP implementations.
Section 3 discusses some of the implications with respect to using
PEP, especially in the context of the global Internet. Finally,
Section 4 discusses some example environments where PEPs are used,
satellite very small aperture terminal (VSAT) environments, mobile
wireless WAN (W-WAN) environments and wireless LAN (W-LAN)
environments. A summary of PEP terminology is included in an
appendix (Section 5).
NOTE: As this is the first version of this draft it may fail to
cover many important aspects related to PEPs. In particular,
this version does not list all the possible implications of
using PEPs nor does the included text on each of the
implications cover all the aspects related to the particular
implication.
Expires December 25, 1999 [Page 3]
INTERNET DRAFT Performance Enhancing Proxies June 1999
2 Types of Performance Enhancing Proxies
There are many types of Performance Enhancing Proxies. Different
types of proxies are used in different environments to overcome
different link characteristics which affect protocol performance.
Note that enhancing performance is not necessarily limited in scope
to throughput. Other performance aspects may also be addressed. For
example, [M-TCP] addresses the issue of keeping TCP connections alive
during periods of disconnection in wireless networks.
The following sections describe some of the key characteristics which
differentiate different types of proxies.
2.1 Layering
A PEP implementation may function at the TCP layer or at the
application layer.
2.1.1 TCP Performance Enhancing Proxies
Most PEP implementations operate at the TCP layer. Such an
implementation is called a TCP Performance Enhancing Proxy (TCP
PEP). For example, in an environment where ACKs may bunch together, a
TCP proxy may be used to simply modify the ACK spacing in order to
improve performance. On the other hand, in an environment with a
large delay*bandwidth product, a TCP proxy may be used to alter the
behaviour of the TCP connection in order to improve its throughput.
TCP PEP implementations may be aware of the type of application being
carried by a TCP connection but, at most, only use this information
to influence their behaviour at the TCP layer.
The term TCP spoofing is sometimes used synonymously for TCP PEP.
However, the term TCP spoofing more accurately applies to only the
subset of TCP PEP implementations which transparently attempt to
alter the behaviour of a TCP connection to improve performance.
2.1.2 Application Layer Proxies
Application layer proxies, on the other hand, operate above the TCP
layer. Today, such proxies are widely used in the Internet and
include Web caches and relay Mail Transfer Agents.
Application layer proxies can be implemented for the purpose of
improving application protocol as well as TCP performance with
respect to a particular application being used with a particular type
Expires December 25, 1999 [Page 4]
INTERNET DRAFT Performance Enhancing Proxies June 1999
of link. Some application protocols employ plenty of (unnecessary)
round trips, lots of headers and/or inefficient encoding which may
have a significant impact on performance, in particular, with long
delay and slow links. In some cases, this unnecessary overhead can
be reduced, in general or for a particular type of link, by using an
application level proxy in an intermediate node. Some examples of
application layer proxies which have been shown to improve
performance in wireless environments are described in [CTC+97] and
[LHKR96].
2.2
This document provides a high level overview of Performance Enhancing
Proxies. Motivations for their development and use are described as
well as some of the consequences of using them.
Expires December 25, 1999 [Page 1]
INTERNET DRAFT Performance Enhancing Proxies June 1999
1 Introduction
The Transmission Control Protocol [RFC0793] (TCP) is used as the
transport layer protocol by many Internet and intranet applications.
However, in certain environments, TCP and other higher layer protocol
performance is limited by the link characteristics of the
environment. [Karn99] discusses various link layer design
considerations that should be taken into account when designing a
link layer service that is intended to support the Internet
protocols. Such design choices may have a significant influence on
the performance and efficiency of the Internet. However, not all
link characteristics, for example, high latency, can be compensated
for by such choices in the link design. And, the cost of
compensating for some link characteristics may be prohibitive for
some technologies. A Performance Enhancing Proxy (PEP) is used to
improve the performance of the Internet protocols in environments
where native performance suffers for some reason, usually a
characteristic of the environment.
This document does not intend to advocate use of PEPs in general. On
the contrary, the end-to-end principle in designing Internet
protocols must be retained the prevailing approach and PEPs should be
used only in specific environments and circumstances. In any
environment where one might consider employing PEP for improved
performance, an end user must be aware of the proxy and the choice of
employing PEP must be under the control of the end user at all
times. This also means that the end user must always be able to
choose end-to-end IP service.
The remainder of this document is organized as follows. Section 2
provides an overview of different kinds of PEP implementations.
Section 3 discusses some of the implications with respect to using
PEP, especially in the context of the global Internet. Finally,
Section 4 discusses some example environments where PEPs are used,
satellite very small aperture terminal (VSAT) environments, mobile
wireless WAN (W-WAN) environments and wireless LAN (W-LAN)
environments. A summary of PEP terminology is included in an
appendix (Section 5).
NOTE: As this is the first version of this draft it may fail to
cover many important aspects related to PEPs. In particular,
this version does not list all the possible implications of
using PEPs nor does the included text on each of the
implications cover all the aspects related to the particular
implication.
Expires December 25, 1999 [Page 3]
INTERNET DRAFT Performance Enhancing Proxies June 1999
2 Types of Performance Enhancing Proxies
There are many types of Performance Enhancing Proxies. Different
types of proxies are used in different environments to overcome
different link characteristics which affect protocol performance.
Note that enhancing performance is not necessarily limited in scope
to throughput. Other performance aspects may also be addressed. For
example, [M-TCP] addresses the issue of keeping TCP connections alive
during periods of disconnection in wireless networks.
The following sections describe some of the key characteristics which
differentiate different types of proxies.
2.1 Layering
A PEP implementation may function at the TCP layer or at the
application layer.
2.1.1 TCP Performance Enhancing Proxies
Most PEP implementations operate at the TCP layer. Such an
implementation is called a TCP Performance Enhancing Proxy (TCP
PEP). For example, in an environment where ACKs may bunch together, a
TCP proxy may be used to simply modify the ACK spacing in order to
improve performance. On the other hand, in an environment with a
large delay*bandwidth product, a TCP proxy may be used to alter the
behaviour of the TCP connection in order to improve its throughput.
TCP PEP implementations may be aware of the type of application being
carried by a TCP connection but, at most, only use this information
to influence their behaviour at the TCP layer.
The term TCP spoofing is sometimes used synonymously for TCP PEP.
However, the term TCP spoofing more accurately applies to only the
subset of TCP PEP implementations which transparently attempt to
alter the behaviour of a TCP connection to improve performance.
2.1.2 Application Layer Proxies
Application layer proxies, on the other hand, operate above the TCP
layer. Today, such proxies are widely used in the Internet and
include Web caches and relay Mail Transfer Agents.
Application layer proxies can be implemented for the purpose of
improving application protocol as well as TCP performance with
respect to a particular application being used with a particular type
Expires December 25, 1999 [Page 4]
INTERNET DRAFT Performance Enhancing Proxies June 1999
of link. Some application protocols employ plenty of (unnecessary)
round trips, lots of headers and/or inefficient encoding which may
have a significant impact on performance, in particular, with long
delay and slow links. In some cases, this unnecessary overhead can
be reduced, in general or for a particular type of link, by using an
application level proxy in an intermediate node. Some examples of
application layer proxies which have been shown to improve
performance in wireless environments are described in [CTC+97] and
[LHKR96].
2.2 Distribution
A PEP implementation may be integrated, i.e. implemented within a
single node, or distributed, i.e. implemented in multiple nodes. An
integrated implementation represents a single point at which
performance enhancement is applied. For example, a proxy might be
implemented to provide impedence matching at the point where wired
and wireless links meet.
A distributed implementation is generally used to surround a
particular link for which performance enhancement is desired. For
example, a PEP implementation for a satellite connection may be
distributed between two proxies located at each end of the satellite
link. A distributed implementation may be symmetric or asymmetric.
A symmetric implementation uses two proxies with essentially
identical behaviour at each end of the link. An asymmetric
implementation is generally used with an asymmetric link and uses two
proxies which behave differently depending on which side of the link
they are on.
2.3 Split Connections
A split connection TCP implementation terminates the TCP connection
received from an end system and establishes a corresponding TCP
connection to the other end system. In a distributed implementation,
this is typically done to allow the use of a connection between the
two proxies optimized for the link. This might be a TCP connection
optimized for the link or it might be another protocol, for example,
a proprietary protocol running on top of UDP. Also, the distributed
implementation might use a separate connection between the proxies
for each TCP connection or it might multiplex the data from multiple
TCP connections across a single connection between the proxies.
In an integrated proxy split connection implementation, the proxy
again terminates the connection from one end system and originates a
separate connection to the other end system. [I-TCP] documents
an example of a single proxy split connection implementation.
Expires December 25, 1999 [Page 5]
INTERNET DRAFT Performance Enhancing Proxies June 1999
In general, an integrated proxy uses a split connection
implementation in order to address a mismatch in TCP capabilities
between two end systems. For example, the scaled TCP windows option
[RFC1323] can be used to extend the maximum amount of TCP data which
can be "in flight" (i.e. sent and awaiting acknowledgement). This is
useful for filling a link which has a high delay*bandwidth product.
If one end system is capable of using scaled TCP windows but the
other is not, the end system which is not capable can set up its
connection with a proxy on its side of the high delay*bandwidth link.
The split connection proxy then sets up a scaled TCP window
connection over the link to the other end system.
Split connection TCP implementations can effectively leverage TCP
performance enhancements optimal for a particular link but which
cannot necessarily be employed safely over the global Internet.
Note that using split connection proxies does not necessarily exclude
simultaneous use of IP for end-to-end connectivity. When employed on
a last hop link, the correct use of a split connection should be
managed per application or per connection and should be under the
control of the end user, allowing the user to decide whether a
particular TCP connection or application makes use of the split
connection proxy or operates end-to-end directly over IP.
In effect, application layer proxies are split connection proxies
with end systems using the proxies as a service related to a
particular application. Therefore, all TCP layer enhancements that
are available with split connection implementations can also be
employed in conjunction with application layer enhancements.
2.4 Transparency
Another key characteristic of a proxy is its degree of transparency.
A proxy may operate totally transparently to the end systems and/or
applications involved (in a connection), requiring no modifications
to the end systems or applications. On the other hand, a proxy
implementation may require modifications to both ends in order to be
used. (This is known as an opaque implementation.) In between, a
proxy implementation may require modifications to only one of the end
systems or applications involved. (This is known as a translucent
implementation.)
It is sometimes useful to think of the degree of transparency of a
PEP implementation at three levels, transparency with respect to the
end systems, transparency with respect to the applications and
transparency with respect to the users. For example, a user who
subscribes to a satellite Internet access service may be aware that
Expires December 25, 1999 [Page 6]
INTERNET DRAFT Performance Enhancing Proxies June 1999
the satellite terminal is providing a performance enhancing service
even though the TCP stack and the applications in the user's PC are
not aware of the proxy which implements it.
Note that the issue of transparency is not the same as the issue of
maintaining the end-to-end semantics of a TCP connection. (The
implications of not maintaining the end-to-end semantics of TCP
connections are discussed in Section 3.) A proxy which simply uses
an ACK spacing mechanism maintains the end-to-end semantics of the
TCP connection while a proxy which uses a split connection
implementation may not. Yet, both can be implemented transparently
to the end systems.
Application layer proxies are usually (but not always)
non-transparent to the end systems and applications (and are almost
always, if not always, non-transparent to the user).
To enable end-to-end IP service at all times, an appropriate practice
when using proxies is to allow the decision of employing a proxy to
be under user control.
2.5 Tunnelling
A proxy may encapsulate TCP messages to carry the messages across a
particular link. A proxy at the other end of the encapsulation
tunnel removes the tunnel wrappers before final delivery to the
receiving end system. A tunnel might be used by a distributed split
connection TCP implementation as the means for connecting the split
connection proxies. A tunnel might also be used to support forcing
TCP connections which use asymmetric routing to go through the end
points of a distributed PEP implementation.
2.6 ACK Handling
The handling of TCP acknowledgements can differ significantly between
different TCP PEP implementations. The following subsections
describe various ACK handling mechanisms.
2.6.1 ACK Spacing
In some TCP PEP implementations the manipulation of TCP
acknowledgements is the entire implementation. ACK spacing is used
to smooth out the flow of TCP acknowledgements traversing a link in
order to improve performance by eliminating bursts of TCP data
segments [Part98].
Expires December 25, 1999 [Page 7]
INTERNET DRAFT Performance Enhancing Proxies June 1999
2.6.2 Local Acknowledgements
In some PEP implementations, TCP data segments received by a proxy
are locally acknowledged by the proxy. This speeds up TCP slow start
and allows the sending end system to quickly open up its transmit
window. Local acknowledgements are automatically used with split
connection implementations.
2.6.3 Local Retransmissions
When local acknowledgements are used, the burden falls upon the TCP
proxy to recover any data which is dropped after the proxy
acknowledges it. The TCP proxy receives the acknowledgements from
the end system receiving the TCP data segments and uses them, along
with appropriate timeouts, to determine when to retransmit lost
data.
Some PEP implementations perform local retransmissions even though
they do not use local acknowledgements to alter TCP connection
performance. Snoop (without SACK) [SNOOP] is a well know example of
such a PEP implementation. Snoop caches TCP data segments it
receives and forwards and then monitors the acknowledgements coming
from the receiving TCP end system for duplicate acknowledgements
(DUPACKs). When DUPACKs are received, Snoop locally retransmits the
lost TCP data segments from its cache, suppressing the
acknowledgement stream flowing to the sending TCP end system until
acknowledgements for new data start being received.
2.7 Compression
Many PEP implementations include support for one or more forms of
compression. (In some PEP implementations, compression may even be
the only mechanism used for performance improvement.) Compression
reduces the number of bytes which need to be sent across a link.
This is useful in general and can be very important for bandwidth
limited links. Some of the benefits of using compression include:
- Improved link efficiency;
- Higher effective link utilization;
- Reduced latency;
- Improved interactive response time;
- Decreased overhead;
Expires December 25, 1999 [Page 8]
INTERNET DRAFT Performance Enhancing Proxies June 1999
- Reduced packet loss rate over lossy links.
Where appropriate, link layer compression is used. [TBD] documents
an example of link layer compression used in conjunction with PEP.
TCP and IP header compression are also frequently used with PEP
implementations. [RFC1144] describes a widely deployed method for
compressing TCP headers. Other header compression algorithms are
described in [RFC2507], [RFC2508] and [RFC2509].
Payload compression is also desirable and is increasing in importance
with today's increased emphasis on Internet security. IP layer (and
above) security mechanisms convert IP payloads into random bit
streams which defeat applicable link layer compression mechanisms by
removing or hiding redundant "information." Therefore, compression
of the payload needs to be applied before security mechanisms are
applied. [RFC2393] defines a framework where common compression
algorithms can be applied to arbitrary IP segment payloads. However,
[RFC2393] compression is not always applicable. Many types of IP
payloads (e.g. images, audio, video and "zipped" files being FTPed)
are already compressed. And, security mechanisms such as SSL and
TLS are applied above the IP layer.
With application layer proxies one can employ application-specific
compression. In particular, with slow links any compression that
effectively reduces transfer volume over is tremendously useful.
Typically an application-specific (or content-specific) compression
mechanism is much more efficient than any generic compression
mechanism. For example, a distributed Web proxy implementation may
implement more efficient binary encoding of HTTP headers, or a single
proxy can employ lossy compression that reduces the image quality of
inline-images on Web pages according to end user instructions, thus
reducing the number of bytes transferred over the slow link and
consequently the response time perceived by the user.
2.8 Handling Periods of Link Disconnection
Periods of link disconnection or link outage are very common with
wireless links. During these periods, a TCP sender does not receive
the expected acknowledgements. Upon expiration of the retransmit
timer, this causes TCP to close its congestion window with all of the
related drawbacks. A TCP proxy may monitor the traffic coming from
the TCP sender towards the TCP receiver behind the disconnected link.
The proxy retains the last ACK, so that it can shut down the TCP
sender's window by sending the last ACK with a window set to zero.
Thus, the TCP sender will go into persist mode.
To make this work in both directions, the TCP receiver behind the
Expires December 25, 1999 [Page 9]
INTERNET DRAFT Performance Enhancing Proxies June 1999
disconnected link must be aware of the current state of the
connection and, in the event of a disconnection, it must be capable
of freezing all timers. [M-TCP] implements such operation. Another
possibility is that the disconnected link is surrounded by a
distributed proxy pair.
In split TCP connection implementations, a period of link
disconnection can easily be hidden from the world on the other side
of the proxy. Consequently, the proxy and its counterpart behind the
disconnected link can employ a modified TCP version which retains the
state and all unacknowledged data segments across the period of
disconnection and then performs local recovery as the link is
reconnected.
2.9 Other Link Specific Enhancements
<Some ideas...>
- Implementing priority-based multiplexing of data (on
a slow link);
- Other possible enhancements.
3 Implications of Using PEP
The following sections describe some of the implications of using
PEP.
3.1 The End-to-end Argument
As indicated in [RFC1958], the end-to-end argument is one of the
architectural principles of the Internet. The basic argument is
that, as a first principle, certain required end-to-end functions can
only be correctly performed by the end systems themselves. Most of
the negative implications associated with using PEP are related to
breaking the end-to-end semantics of connections. This is one of
the main reasons why PEPs are not recommended for general use.
As indicated in Section 2.4, not all PEP implementations break the
end-to-end sematics of connections. However, split connection PEP
implementations, especially transparent split connection PEP
implementations, often do.
Expires December 25, 1999 [Page 10]
INTERNET DRAFT Performance Enhancing Proxies June 1999
3.1.1 Security
The most detrimental negative implication of breaking the end-to-end
semantics of a connection is that it disables end-to-end use of IP
layer security (IPsec). If, on the other hand, IPsec is employed
end-to-end, encryption of IP packets via IPSEC's ESP header (in
either transport or tunnel mode) renders the TCP header and payload
unintelligible to intermediate PEPs. This precludes PEPs from
working, because they need to examine the TCP headers in both
directions. However, if the end user can select end-to-end IP
service for the IPSEC traffic, the encrypted traffic is not subject
to the possible performance enhancements but the other traffic is.
With a non-transparent PEP implementation, if the end systems trust
the proxy, IPsec can be used separately between each end system and
the proxy. However, in most cases this is an undesireable or
unacceptable alternative as the end systems can not trust the proxy.
In addition, this is not as secure as end-to-end security. And, it
can lead to potentially misleading security level assumptions by the
end systems. If the two end systems negotiate different levels of
security with the proxy, the end system which negotiated the stronger
level of security may not be aware that a lower level of security is
being provided for part of the connection. (The proxy could be
implemented to prevent this from happening by being smart enough to
force the same level of security to each end system.)
With a transparent PEP implementation, it is difficult for the end
systems to trust the proxy because they are not aware of its
existence. However, IPsec can be implemented between the two proxies
of a distributed implementation. And, if the PEP implementation is
non-transparent to the users, the users could configure their end
systems to use the proxies as the end points of an IPsec tunnel. In
any case, the authors are currently not aware of any PEP
implementations, transparent or non-transparent, which provide
support for IPsec.
Note that even when a PEP implementation does not break the
end-to-end sematics of a connection, the PEP implementation may not
be able to function in the presence of IPsec. For example, it is
difficult to do ACK spacing if the proxy cannot reliably determine
which IP packets contain ACKs.
In most cases, security applied above the TCP layer can be used with
PEP, especially TCP PEP.
3.1.2 Fate Sharing
Another important aspect of the end-to-end argument is fate sharing.
If a failure occurs in the network, the ability of the connection to
Expires December 25, 1999 [Page 11]
INTERNET DRAFT Performance Enhancing Proxies June 1999
survive the failure depends upon how much state is being maintained
on behalf of the connection in the network. If no connection specific
state resides in the network as in case of regular end-to-end
operation, then a failure in the network will only break the
connection if there is no alternate path through the network between
the end systems. And, if there is no path, both end systems can
detect this. However, if the connection depends upon some state being
stored in the network (e.g. in a proxy), then a failure in the
network (e.g. the node containing the proxy crashes) causes this
state to be lost, forcing the connection to terminate even if an
alternate path through the network exists.
The importance of this aspect of the end-to-end argument with respect
to PEP is very PEP implementation dependent. Sometimes coincidentally
but more often by design, PEP is used in environments where there is
no alternate path between the end systems and, therefore, a failure
of the intermediate node containing the proxy would result in the
termination of the connection in any case. And, even when this is not
the case, the users may choose to accept the risk of the proxy
crashing in order to take advantage of the performance gains offered
by the PEP implementation. Note that accepting the risk must be
under the control of the user and the user must always have the
option to choose end-to-end IP service.
3.1.3 End-to-end Acknowledgements
Another aspect of the end-to-end argument is that of acknowledging
the receipt of data end-to-end. Breaking the end-to-end semantics of
a TCP connection prevents TCP acknowledgements from being used for
this purpose by an application. If an application uses TCP
acknowledgements as its indication of successful end-to-end delivery
of data, the application may not be a good candidate for use with
PEP.
Using TCP acknowledgements as an indication of reliable delivery at
the application layer is not necessarily a good idea. First, the TCP
implementation may not provide TCP acknowledgement information to the
application. Second, the TCP acknowledgement only indicates that
data was delivered to the TCP implementation on the other end system.
It does not guarantee that the data was delivered to the application
layer on the other end system. Therefore, also according to the
end-to-end argument, a well designed application must use an
application layer acknowledgement to ensure end-to-end delivery
of application layer data. PEP implementations generally do not
interfere with end-to-end application layer acknowledgements, and,
if they do, they must take full responsibility for delivering
the application data to its ultimate destination. For example,
Expires December 25, 1999 [Page 12]
INTERNET DRAFT Performance Enhancing Proxies June 1999
that is how relay MTAs operate when delivering Internet mail
messages.
3.2 Other Implications
TBD in later versions:
- breaking the end-to-end failure diagnostics
- problems with mobile environments where the PEP related state
information with should be transferred to the new PEP node
during a handoff.
- other possible implications
4 PEP Environment Examples
The following sections describe examples of environments where PEP is
currently used to improve performance.
4.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. An outroute is
typically much larger than an inroute. However, multiple inroutes
can be used with each outroute.
VSAT networks are generally used to implement private networks
(i.e. intranets) for enterprises (e.g. corporations) with
geographically dispursed sites. VSAT networks are rarely, if ever,
used to implement Internet connectivity except at the edge (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 appropriate) NAT [NAT] devices.
4.1.1 VSAT Network Characteristics
With respect to TCP performance, VSAT networks exhibit the following
subset of the satellite characteristics documented in [RFC2488]:
Expires December 25, 1999 [Page 13]
INTERNET DRAFT Performance Enhancing Proxies June 1999
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 delay*bandwidth 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 acknowledgements [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.
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 a network availability
point of view) and VSAT networks are generally engineered to work
during these conditions but not to optimize performance during these
conditions.
Expires December 25, 1999 [Page 14]
INTERNET DRAFT Performance Enhancing Proxies June 1999
4.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 no one dominant PEP implementation used with VSAT networks.
Each VSAT network vendor tends to implement their own version of PEP,
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. SatBooster [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 acknowledgements
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 are usually translucent, requiring a configuration
change in the remote site end system to route TCP packets to the
Expires December 25, 1999 [Page 15]
INTERNET DRAFT Performance Enhancing Proxies June 1999
remote site proxy. In some cases, the PEP implementation is actually
integrated transparently into the end system node itself, using a
"bump in the stack" approach.
4.1.3 VSAT Network PEP Motivation
TBD (in later versions):
<Why>
- Intranet versus Internet
- Highly asymmetric links
- Support for "non-modern" TCP stacks
4.2 W-WAN Environments
TBD (in later versions):
[ text covering W-WAN example(s) is intended to include at least the
following issues: ]
4.2.1 W-WAN Network Characteristics
<Characteristics>
- low bandwidth
- high latency
- high BER, or long variable delays due to local link-layer
error recovery
- some W-WAN links have a lot internal buffers which tend to
accumulate data, thus resulting in increased round-trip delay
- unexpected link disconnections may occur frequently (or
intermittent link outages)
- (re)setting link-connection up takes long time
- typically last-hop link to the end user
- 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
Expires December 25, 1999 [Page 16]
INTERNET DRAFT Performance Enhancing Proxies June 1999
4.2.2 W-WAN PEP Implementations
<How/What>
- Mowgli approach [MOWGLI]: Split TCP together with application
layer proxies and W-WAN link specific protocol [KRLKA97] or
with corresponding protocol modifications, compression in
various forms, reduction of round trips, priority-based
multiplexing of data over the W-WAN link, link-level flow
control to prevent data from accumulating into the W-WAN link
internal buffers, ...
<Why>
- transfer volume must be reduced to make Internet access usable,
(long) link disconnections must not abort active (bulk data)
transfers, slow W-WAN link should be efficiently shielded from
excess traffic and the global (wired) Internet congestion,
(all) applications can not be made mobility/W-WAN aware in short
time frame or maybe ever, interactive traffic must be transmitted
in timely manner even if there are other simultaneous bandwidth
intensive (background) transfers...
4.3 W-LAN Environments
Wireless LANs (W-LAN) are typically organized in a cellular topology
where a base station with a W-LAN transceiver is controlling a single
cell. A cell is defined in terms of the coverage area of the base
station. The base stations are directly connected to the wired
network. The base station 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 tranceivers 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 base station of the new cell. This is known as
a handoff.
4.3.1 W-LAN Network Characteristics
Current wireless LANs typically provide link bandwidth from 1 Mbps to
10 Mbps, most typically bandwidth being 1 or 2 Mbps. In the future,
wide deployment of higher bandwidths up to 20 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 ... <TBD>.
Expires December 25, 1999 [Page 17]
INTERNET DRAFT Performance Enhancing Proxies June 1999
Wireless LANs are error-prone due to wireless link corruption. TCP
performance over wireless LANs or a network path involving a W-LAN
link suffers as packet losses due to wireless bit errors tend to
occur in bursts. In addition, consecutive packet losses may occur
also during handoffs.
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.
4.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 per each TCP connection.
For a data transfer to a mobile host, the Snoop agent caches
unacknowledged TCP data which it forwards to the (wired network)
receiver and monitors the corresponding ACKs. It does two things:
1. Retransmits any lost packets locally by using local timers and
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.
Thus, the Snoop protocol is designed to avoid unnecessary fast
retransmits by the TCP sender, when 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 the sender 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, receiver R receives packets A, C, D, E and B (in
that order). Receipt of packets C, D and E triggers duplicate
acknowledgement. When the TCP sender receives three duplicate
acknowledgements, 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 acknowledgements. The fast retransmit at the TCP sender
occurs despite the local retransmit on the wireless link, degrading
Expires December 25, 1999 [Page 18]
INTERNET DRAFT Performance Enhancing Proxies June 1999
throughput. Snoop deals with this problem by dropping TCP dupacks
appropriately (at the base station).
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 th TCP sender of the packet
losses on the wireless link, one possibility to implement them is
using the Selective Acknowledgment (SACK) option of the 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 adviced 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 in
the later 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, one of the unreserved bits in the TCP header is
suggested to be used for ELN [SNOOPELN]. The Snoop agent keeps track
of the holes that correspond to segments lost over the wireless link.
When (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.
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 a stop-and-go protocol (or otherwise
delivers packets in-order), then this scheme is not very beneficial.
Also, if the bandwidth*delay product of the wireless link is smaller
than four segments, the probability that the snoop agent will have an
opportunity to send three new packets before a lost packet is
retransmitted is small. Since at least three dupacks are needed to
trigger a fast retransmit, with a wireless bandwidth*delay product of
less than four packets, schemes such as Snoop would not be necessary
Expires December 25, 1999 [Page 19]
INTERNET DRAFT Performance Enhancing Proxies June 1999
(unless the link layer is not designed properly). Conversely, when
the wireless bandwidth*delay product is large enough, Snoop can
provide significant performance improvement (compared with standard
TCP).
[ TBD: some text how Snoop tries to alleviate the problem with small
windows ]
Snoop requires the base station to examine and operate on the traffic
between the mobile host and the TCP server on the wired Internet.
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, if the SNOOP agent
retransmits the TCP data segments ("at the transport layer") across
the wireless link, this may duplicate efforts by the link layer.
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.
<Why>
- to alleviate local link pkt drops due to high-BER (wireless) link
5 Security Considerations
The security implications of using PEP are discussed in Section
3.1.1.
<Are there other security considerations which need mentioning?>
6 Appendix - 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.)
Expires December 25, 1999 [Page 20]
INTERNET DRAFT Performance Enhancing Proxies June 1999
6.1 Definitions
ACK spacing
Delayed forwarding of acknowledgements in order to space them
out.
application layer PEP
Performance enhancement operating above the TCP layer. May be
aimed at improving TCP or application protocol performance (or
both).
asymmetric link
A link which has different rates for the forward channel (used for
data segements) 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, expressed as a percent of the raw bandwidth of the link.
gateway
Has several meanings depending on context:
- An access point to a particular link;
- 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 acknoledged. More precisely, data sent for
which the sender has not yet received the acknowledgement.
local acknowledgement
The generation of acknowledgements by an entity in the path
Expires December 25, 1999 [Page 21]
INTERNET DRAFT Performance Enhancing Proxies June 1999
between two end systems in order to allow the sending end system
to transmit more data without waiting for end-to-end
acknowledgements.
opaque
Requires changes to be made to both end systems of a connection.
proxy
An entity in the network acting on behlaf of an end system or user
(with or without the knowledge of the end system or user).
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 acknowledgements
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 [SNOOP].
split connection
A connection that has been terminated before reaching the
destination end system in order to initiate a second connection
towards the end system.
TCP PEP
Performance enhancement operating at the TCP layer. Aimed at
improving TCP performance.
TCP splitting
Using one or more split connections to improve TCP performance.
TCP spoofing
Sometimes used as a synonym for TCP PEP but more accurately refers
to using transparent mechanisms to improve TCP performance.
Expires December 25, 1999 [Page 22]
INTERNET DRAFT Performance Enhancing Proxies June 1999
translucent
Requires changes to be made at only one end system of a
connection.
transparent
Requires no changes to be made to either end system of a
connection.
tunnelling
The process of wrapping a packet received from an end system
inside of another packet to transition a particular link.
7 Acknowledgements
This document grew out of the Internet-Drafts "TCP Performance
Enhancing Proxy Terminology" and "Long Thin Networks" and the work
done in the IETF TCPSAT working group.
8 References
[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," in proceedings of MobiCom'97, Budapest, Hungary,
September 1997.
[FLASH] http://www.flash-networks.com/
[FOURELLE] http://www.fourelle.com/
[HNS] http://www.hns.com/
[I-TCP] A. Bakre, B.R. Badrinath, "I-TCP: Indirect TCP for Mobile
Hosts," in proceedings of the 15th International Conference on
Distributed Computing Systems (ICDCS), May 1995.
[Karn99] P. Karn, "Advice for Internet Subnetwork Designers,"
Internet-Draft http://people.qualcomm.com/karn/pilc.txt
(work in progress).
[KRLKA97] Kojo, M., Raatikainen, K., Liljeberg, M., Kiiskinen,
J., Alanko, T., "An Efficient Transport Service for Slow Wireless
Telephone Links," in IEEE Journal on Selected Areas of
Expires December 25, 1999 [Page 23]
INTERNET DRAFT Performance Enhancing Proxies June 1999
Communication, volume 15, number 7, September 1997.
[LHKR96] M. Liljeberg, H. Helin, M. Kojo, K. Raatikainen, "Mowgli
WWW Software: Improved Usability of WWW in Mobile WAN
Environments," in proceedings of IEEE Global Internet 1996
Conference, London, UK, November 1996.
[MOWGLI] Kojo, M., Raatikainen, K., Alanko, T., "Connecting Mobile
Workstations to the Internet over a Digital Cellular Telephone
Network," in Proc. Workshop on Mobile and Wireless Information
Systems (MOBIDATA), Rutgers University, NJ, November 1994.
Available at: http://www.cs.Helsinki.FI/research/mowgli/. Revised
version published in Mobile Computing, pp. 253-270, Kluwer, 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.
[NAT] P. Srisuresh, M. Holdrege, "IP Network Address Translator
(NAT) Terminology and Considerations," Internet-Draft
draft-ietf-nat-terminology-03.txt, June 1999 (work in progress).
[Part98] C. Partridge, "ACK Spacing for High Delay-Bandwidth Paths
with Insufficient Buffering," September 1998. Internet-Draft
draft-rfced-info-partridge-01.txt (work in progress).
[RFC0793] J. Postel, "Transmission Control Protocol," STD 7,
RFC 793, September 1981.
[RFC1122] R. Braden, "Requirements for Internet Hosts --
Communications Layers," STD 3, RFC 1122, October 1989.
[RFC1144] V. Jacobson, "Compressiing TCP/IP Headers for Low-Speed
Serial Links," RFC 1144, February 1990.
[RFC1323] V. Jacobson, R. Braden, D. Borman, "TCP Extensions for
High Performance," RFC 1323, May 1992.
[RFC1958] B. Carpenter, "Architectural Principles of the Internet,"
RFC 1958, June 1996.
[RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and Romanow, A.,
"TCP Selective Acknowledgment Options," RFC 2018, October, 1996.
[RFC2393] A. Shacham, R. Monsour, R. Pereira, M. Thomas, "IP Payload
Compression Protocol (IPcomp)," RFC 2393, December 1998.
[RFC2488] M. Allman, D. Glover, L. Sanchez, "Enhancing TCP Over
Expires December 25, 1999 [Page 24]
INTERNET DRAFT Performance Enhancing Proxies June 1999
Satellite Channels using Standard Mechanisms," BCP 28, RFC 2488,
January 1999.
[RFC2507] M. Degermark, B. Nordgren, S. Pink, "IP Header
Compression," RFC 2507, February 1999.
[RFC2508] S. Casner, V. Jacobson, "Compressing IP/UDP/RTP Headers
for Low-Speed Serial Links," RFC 2508, February 1999.
[RFC2509] M. Engan, S. Casner, C. Bormann, "IP Header Compression
over PPP," RFC 2509, February 1999.
[SNOOP] H. Balakrishnan, S. Seshan, E. Amir, R. Katz, "Improving
TCP/IP Performance over Wireless Networks," in proceedings of the
1st ACM Conference on Mobile Communications and Networking
(Mobicom), Berkeley, CA, November 1995.
[SNOOPELN] H. Balakrishnan, R. Katz, "Explicit Loss Notification
and Wireless Web Performance," In Proc. IEEE Globecom 1998,
Internet Mini-Conference, Sydney, Australia, November 1998.
[SPACENET] http://www.spacenet.com/
9 Authors' Addresses
Questions about this document may be directed at:
Expires December 25, 1999 [Page 25]
INTERNET DRAFT Performance Enhancing Proxies June 1999
John Border
Hughes Network Systems
11717 Exploration Lane
Germantown, Maryland 20876
Voice: +1-301-601-4099
Fax: +1-301-601-4275
E-Mail: border@hns.com
Markku Kojo
University of Helsinki/Department of Computer Science
P.O. Box 26 (Teollisuuskatu 23)
FIN-00014 HELSINKI
Finland
Voice: +358-9-7084-4179
Fax: +358-9-7084-4441
E-Mail: kojo@cs.helsinki.fi
Jim Griner
NASA Glenn Research Center
MS: 54-2
21000 Brookpark Orad
Cleveland, Ohio 44135-3191
Voice: +1-216-433-5787
Fax: +1-216-433-8705
E-Mail: jgriner@grc.nasa.gov
Gabriel E. Montenegro
Sun Labs Networking and Security Group
Sun Microsystems, Inc.
901 San Antonio Road
Mailstop UMPK 15-214
Mountain View, California 94303
Voice: +1-650-786-6288
Fax: +1-650-786-6445
E-Mail: gab@sun.com
10 Full Copyright Statement
Copyright (C) The Internet Society (1999). 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
Expires December 25, 1999 [Page 26]
INTERNET DRAFT Performance Enhancing Proxies June 1999
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.
Expires December 25, 1999 [Page 27]
