Internet Engineering Task Force Hari Balakrishnan
Internet Draft MIT LCS
Document: draft-ietf-pilc-asym-03.txt Venkata N. Padmanabhan
Microsoft Research
Gorry Fairhurst
University of Aberdeen, U.K.
Mahesh Sooriyabandara
University of Aberdeen, U.K.
Category: Informational / BCP March 2001
TCP Performance Implications of Network Asymmetry
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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 Internet- 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.
1. Abstract
This document describes TCP performance problems that arise because
of asymmetric effects. These problems arise in several access
networks, including bandwidth-asymmetric networks and packet radio
networks, for different underlying reasons. However, the end result
on TCP performance is the same in both cases: performance often
degrades significantly because of imperfection and variability in
the ACK feedback from the receiver to the sender. This document
details several mitigations to these effects, which have either been
proposed and evaluated in the literature, or are currently deployed
in different networks. These solutions use a combination of local
link-layer techniques, subnetwork, and end-to-end mechanisms,
consisting of: (i) techniques to manage the reverse channel used by
ACKs, typically using header compression or reducing the frequency
of TCP ACKs, (ii) techniques to handle this reduced ACK frequency
to retain the TCP sender's acknowledgment-triggered self-clocking
and (iii) techniques to schedule the data and ACK packets in the
return path to improve performance in the presence of two way
traffic.
Expires September 2001 [page 1]
INTERNET DRAFT PILC - Asymmetric Links March 2001
2. Conventions used in this document
FORWARD DIRECTION: The dominant direction of data transfer over an
asymmetric network. It corresponds to the direction with better link
characteristics in terms of bandwidth, latency, error rate, etc. We
term data transfer in the forward direction as a "forward transfer."
REVERSE DIRECTION: The direction in which acknowledgments of a
forward TCP transfer flow. Data transfer could also happen in this
direction (and it is termed "reverse transfer"), but it is typically
less voluminous than that in the forward direction. The reverse
direction typically exhibits worse link characteristics than the
forward direction.
DOWNSTREAM: Same as the forward direction.
UPSTREAM: Same as the reverse direction.
ACK: A cumulative TCP acknowledgment. In this document, we use this
term to refer to a TCP segment that carries a cumulative
acknowledgement but no data.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in [RFC2119].
3. Motivation
Asymmetric characteristics are exhibited by several network
technologies, including cable modems, direct broadcast satellite
with interactive return channels, Very Small Aperture satellite
Terminals (VSAT), Asymmetric Digital Subscriber Line (ADSL), Hybrid
Fiber-Coaxial (HFC), and several packet radio networks. Given that
these networks are increasingly being deployed as high-speed access
networks, it is highly desirable to achieve good TCP performance
over such networks. However, the asymmetry of the networks often
makes this challenging.
Asymmetry may manifest itself as a difference in transmit and
receive bandwidth, an imbalance in the packet loss rate, or
differences between the transmit and receive paths [udlr]. For
example, when bandwidth is asymmetric such that the reverse path
used by TCP ACKs is constrained, the slow or infrequent ACK feedback
degrades TCP performance in the forward direction. Even when
bandwidth is symmetric, asymmetry in the underlying medium access
control (MAC) protocol could make it expensive to transmit ACKs
(disproportionately to the size of the ACKs) in one direction. In
wireless packet radio networks, the asymmetry of the MAC protocol
is often a fundamental consequence of the hub-and-spokes
architecture of the network (e.g., a single base station that
communicates with multiple mobile stations) rather than an artifact
Expires September 2001 [page 2]
INTERNET DRAFT PILC - Asymmetric Links March 2001
of poor engineering choices. Satellite networks employing dynamic
bandwidth on demand (BoD), are another example of systems that
consume MAC resources for each packet sent. These MAC interactions
may result in significant degradation of TCP performance.
Despite the technological differences between asymmetric-bandwidth
and packet radio networks, TCP performance suffers in both these
kinds of networks for the same fundamental reason: the imperfection
and variability of ACK feedback. This document discusses the problem
in detail and describes several techniques that may reduce or
eliminate the constraints.
4. How does asymmetry degrade TCP performance?
This section describes the implications of network asymmetry on TCP
performance. We refer the reader to [BPK99, Bal98, Pad98] for more
details and experimental results.
4.1 Bandwidth asymmetry
We first discuss the problems that degrade unidirectional transfer
performance in bandwidth-asymmetric networks. Depending on the
characteristics of the reverse path, two types of situations arise
for unidirectional traffic over such networks: when the reverse
bottleneck link has sufficient queuing to prevent packet (ACK)
losses, and when the reverse bottleneck link has a small buffer. We
consider each situation in turn.
If the reverse bottleneck link has deep queues so that ACKs do not
get dropped on the reverse path, then performance is a strong
function of the normalized bandwidth ratio, k, defined in [LMS97]. k
is the ratio of the raw bandwidths divided by the ratio of the
packet sizes used in the two directions. For example, for a 10 Mbps
forward channel and a 50 Kbps reverse channel, the raw bandwidth
ratio is 200. With 1000-byte
data packets and 40-byte ACKs, the ratio of the packet sizes is 25.
This implies that k is 200/25 = 8. Thus, if the receiver acknowl-
edges more frequently than one ACK every k = 8 data packets, the
reverse bottleneck link will get saturated before the forward
bottleneck link does, limiting the throughput in the forward
direction.
If k > 1 and ACKs are not delayed (in the sense of TCP's delayed ack
algorithm) or dropped (at the reverse bottleneck router), TCP ACK-
clocking breaks down. Consider two data packets transmitted by the
sender in quick succession. En route to the receiver, these packets
get spaced apart according to the bottleneck link bandwidth in the
forward direction. The principle of ACK clocking is that the ACKs
generated in response to these packets preserve this temporal
spacing all the way back to the sender, enabling it to transmit new
data packets that maintain the same spacing [Jac88]. However, the
Expires September 2001 [page 3]
INTERNET DRAFT PILC - Asymmetric Links March 2001
limited reverse bandwidth and queuing at the reverse bottleneck
router alters the inter-ACK spacing observed at the sender. When
ACKs arrive at the bottleneck link in the reverse direction at a
faster rate than the link can support, they get queued behind one
another. The spacing between them when they emerge from the link is
dilated with respect to their original spacing, and is a function of
the reverse bottleneck bandwidth. Thus the sender clocks out new
data at a slower rate than if there had been no queuing of ACKs. No
longer is the performance of the connection dependent on the forward
bottleneck link alone; instead, it is throttled by the rate of
arriving ACKs. As a side effect, the sender's rate of congestion
window growth slows down too.
A second side effect also arises when the upstream bottleneck link
on the reverse path is saturated. The saturated link causes
persistent queuing of packets, leading to an increasing path RTT
observed by all end systems using the bottleneck link. This can
impact the protocol control loops, and may also trigger false time
out (underestimation of the path RTT by the application).
A different situation arises when the upstream bottleneck link has a
relatively small amount of buffer space to accommodate ACKs. As the
transmission window grows, this queue fills and ACKs are dropped. If
the receiver acknowledges every packet, only one of every k ACKs
gets through to the sender, and the remaining (k-1) are dropped due
to buffer overflow at the reverse channel buffer (here k is the
normalized bandwidth ratio as before). In this case, the reverse
bottleneck link capacity and slow ACK arrival are not directly
responsible for any degraded performance. However, there are three
important reasons for degraded performance in this case because ACKs
are infrequent.
1. First, the sender transmits data in large bursts, limited only by
the available congestion window (cwnd). If the sender receives only
one ACK in k, it transmits data in bursts of k (or more) segments
because each ACK shifts the sliding window by at least k
(acknowledged) segments. This increases the likelihood of data loss
along the forward path especially when k is large, because routers
do not handle large bursts of packets well.
2. Second, TCP sender implementations increase their congestion
window by counting the number of ACKs they receive and not on how
much data is actually acknowledged by each ACK. Thus fewer ACKs
imply a slower rate of growth of the congestion window, which
degrades performance over long-delay connections.
3. Third, the sender's fast retransmission and recovery algorithms
[RFC 2581] are less effective when ACKs are lost. The sender may not
receive the threshold number of duplicate ACKs even if the receiver
transmits more than the required number. Furthermore, the sender may
not receive enough duplicate ACKs to adequately inflate its window
during fast recovery.
Expires September 2001 [page 4]
INTERNET DRAFT PILC - Asymmetric Links March 2001
4.2 MAC protocol interactions
The interaction of TCP with MAC protocols may degrade end-to-end
performance. Variable round-trip delays and ACK queuing are the main
symptoms of this problem.
One example, is the impact on terrestrial wireless networks [Bal98].
The need for the communicating peers to first synchronize via the
RTS/CTS protocol before communication and the significant turn-
around time for the radios result in a high per-packet overhead.
Furthermore, since the RTS/CTS exchange needs to back-off
exponentially when the polled radio is busy (for example, engaged in
a conversation with a different peer), this overhead is variable.
This leads to large and variable communication latencies in packet-
radio networks. In addition, an asymmetric workload (with most data
flowing in one direction to clients), tends to cause ACKs to get
queued in certain radio units (especially in the client modems),
exacerbating the variable communication latencies.
These variable latencies and queuing of ACKs adversely affect smooth
data flow. In particular, TCP ACK traffic interferes with the flow
of data and increases the traffic load on the system. For example,
experiments conducted on Metricom's Ricochet packet radio network
[Met] in 1996 and 1997 clearly demonstrated the effect of the radio
turnarounds and increased RTT variability, which degrade TCP
performance. It is not uncommon for TCP connections to experience
timeouts that last between 9 and 12 seconds each. As a result, a
connection may be idle for a very significant fraction of its
lifetime. (We observed instances in the context of the Ricochet
network where the idle time is 35% of the total transfer time!)
Clearly, this leads to gross under-utilization of the available
bandwidth. These observations are not an artifact of a particular
network, but in fact show up in many wireless situations.
Why are these timeouts so long in duration? Ideally, the round-trip
time estimate (srtt) of a TCP data transfer will be relatively
constant (i.e., have a low linear deviation, rttvar). Then the TCP
retransmission timeout, set to srtt + 4*rttvar, will track the
smoothed round-trip time estimate and respond well when multiple
losses occur in a window. Unfortunately, this is not true for
connections in the Ricochet network. Because of the high variability
in RTT, the retransmission timer is on the order of 10 seconds,
leading to the long idle timeout periods.
In general, it is correct for the retransmission timer to trigger a
segment retransmission only after an amount of time dependent on
both the round-trip time and the linear (or standard) deviation. If
only the mean or median round-trip estimates were taken into
account, the potential for spurious retransmissions of segments
still in transit is large. Connections traversing multiple wireless
hops are especially vulnerable to this effect, because it is now
more likely that the radio units may already be engaged in
conversation with other peers.
Expires September 2001 [page 5]
INTERNET DRAFT PILC - Asymmetric Links March 2001
Satellite subnetworks often employed shared frequency channels and
arbitrate use of the satellite bandwidth by using Medium Access
Control (MAC) protocols which employ a Bandwidth on Demand (BoD)
scheme. Such links, like wireless links, also exhibit a per packet
transmission overhead (each packet sent consumes satellite resource
which could otherwise be used to transfer useful DATA). For this
reason many Very Small Aperture satellite Terminals (VSATs) employ
some form of asymmetric mitigation technique to optimise the overall
system performance.
Note that the subnetwork MAC contention problem is a significant
function of the number of packets (e.g., ACKs) transmitted rather
than their size. In other words, there is a significant cost to
transmitting a packet regardless of its size.
4.3 Bi-directional traffic
We now consider the case when TCP transfers simultaneously occur in
opposite directions over an asymmetric network. An example scenario
is one in which a user sends out data upstream (for example, an e-
mail message) while simultaneously receiving other data downstream
(for example, Web pages). For ease of exposition, we restrict our
discussion to the case of one connection in each direction.
In the presence of bi-directional traffic, the effects discussed in
Section 4.1 are more pronounced, because part of the uplink
bandwidth is used up by the reverse transfer. This effectively
increases the degree of bandwidth asymmetry for the forward
transfer. In addition, there are other effects that arise due to the
interaction between data packets of the reverse transfer and ACKs of
the forward transfer. Suppose the reverse connection is initiated
first and that it has saturated the reverse channel and buffer with
its data packets at the time the forward connection is initiated.
There is then a high probability that many ACKs of the newly
initiated forward connection will encounter a full reverse channel
buffer and hence get dropped. Even after these initial problems,
ACKs of the forward connection could often get queued up behind
large data packets of the reverse connection, which could have long
transmission times (e.g., it takes about 280 ms to transmit a 1 KB
data packet over a 28.8 Kbps line). This causes the forward transfer
to stall for long periods of time. It is only at times when the
reverse connection loses packets (due to a buffer overflow at an
intermediate router) and slows down that the forward connection gets
the opportunity to make rapid progress and quickly build up its
congestion window.
When ACKs are queued behind other traffic for appreciable periods of
time, the burst nature of TCP traffic and self-synchronising effects
may result in an effect known as ACK Compression [ZSC91] which
reduces the throughput of TCP. It occurs when a series of ACKs, in
one direction are queued behind a burst of other packets (e.g. DATA
packets traveling in the same direction) and become compressed in
Expires September 2001 [page 6]
INTERNET DRAFT PILC - Asymmetric Links March 2001
time. This, in turn, results in an intense burst of DATA in the
other direction, (in response to the burst of compressed ACKs
arriving at the server). This phenomenon has been investigated in
detail for bi-directional traffic, and recent analytical work
[LMS97] has predicted ACK Compression may also result from
asymmetry, and was observed in practical asymmetric satellite
networks [FSS01].However in the case of extreme asymmetry, effect of
ACK dilation may be significant rather than ACK compression. That
is, the inter-ACK spacing may actually increase due to queuing.
In summary, any sharing of the return path by multiple flows (e.g.
multiple TCP flows to the same host, or flows to a number of hosts
sharing a common uplink) increases the level of ACK congestion. The
presence of bi-directional traffic exacerbates the constraints
introduced by bandwidth asymmetry because of the adverse interaction
between (large) data packets of an upstream connection and the ACKs
of a downstream connection.
4.4 Forward path packet losses due to link errors
In the case of long delay satellite paths another complication may
arise due to the slow return channel. In these type of networks TCP
large windows is used for maximum utilization of the forward
channel. If the forward channel is subjected to random errors (which
is common in any wireless path) a packet loss from a large window of
data will generate large number of back-to-back duplicate ACKs. In
the worse case the duplicate ACKs queue at the return channel may
delay the ACK for retransmitted packet, (send after triggering fast
retransmission) ultimately leading to a timeout. Effect of such a
time out can lead to premature ending of Slow Start or reduction of
congestion window to a smaller value resulting poor forward path
throughput.
This can be avoided by deleting duplicate ACKs up to a threshold
value [Min00, Cal98] to allow fast retransmission and avoid early
timeouts. The same scenario can be seen when TCP SACK option is
used. In this case return channel will be saturated from back to
back ACKs with SACK blocks. Because SACK packet is relatively larger
than a duplicate Acknowledgement probability of time out followed by
a Fast Retransmission is high.
4.5 Examples of existing systems with asymmetry
In heterogeneous networks, the diverse power and transceiver
capabilities of the nodes and economical considerations may result
in asymmetry in transmission and reception. These aspects will come
in to play in both commercial public networks (and especially in
military networks where highly asymmetric networks with a bandwidth
ratio exceeding 100:1 may be found (e.g. [KSG98])). Two such
networks used by NATO provide Internet access to in-transit/isolated
nodes and/or shipboard terminals [Seg00]. A high bandwidth forward
Expires September 2001 [page 7]
INTERNET DRAFT PILC - Asymmetric Links March 2001
path (3Mbps and 2Mpbs) from high power commercial DVB transponders
with narrowband return channel (9.6kbps and 2400bps) from UHF/DAMA
or Inmarsat satellite links is used to built the network. The
bandwidth asymmetric ratios in these networks are approximately
300:1 and 800:1. The performance of these asymmetric networks are
improved by deploying a scheme called ACK decimation (see section
6.2.2).
Another area where asymmetry may arise is when digital satellite TV
(e.g. DVB-S) is used as a bearer network for forward transmission at
a rate of typically 38-45 Mbps, with the return channel provided by
a terrestrial modem [CLC99]. Depending on the service provided, the
networks can be build with high bandwidth asymmetry. At present
Direct-PC uses a similar architecture with a forward DVB-S channel
with typical 28.8kbps dial up modem return to provide Internet
service to homes. The asymmetric ratio seen by a TCP connection of
such a network can be higher than 15: 1. ACK filtering has been used
as one technique to improve the TCP performance in the forward path
[ASB 96]. Commercial networks with low asymmetry (i.e. in range from
4 to 50) may still benefit from using ACK modification schemes.
5. Improving TCP performance using host modifications
There are two key issues that need to be addressed in order to
improve TCP performance over asymmetric networks. The first issue is
to manage bandwidth usage on the reverse link, used by ACKs (and
possibly other traffic). A number of techniques exist which work by
reducing the number of ACKs that flow over the reverse channel. This
has the side effect of potentially destroying the desirable self-
clocking property of the TCP sender where new data transmissions are
triggered by incoming ACKs. Thus, the second issue is to avoid any
adverse impact of infrequent ACKs.
Each of these issues can be handled by local link-layer solutions
and/or by end-to-end techniques. In this section, we discuss end-to-
end modifications. The next section describes several techniques
which do not require end-to-end changes.
5.1 Modified delayed ACKs
There are two standard methods that can be used by TCP receivers to
generated acknowledgments. The method outlined in [RFC793]
generates an ACK for each incoming DATA segment. [RFC1122] states
that hosts SHOULD use "delayed acknowledgments". Using this
algorithm, an ACK is generated for every second full-sized segment
(d=2), or if a second full-size segment does not arrive within a
given timeout (which must not exceed 500 ms [RFC 1122], typically
less than 200 ms). Relaxing the latter constraint (i.e. allowing
d>2) could reduce the rate of ACKs returned.
Expires September 2001 [page 8]
INTERNET DRAFT PILC - Asymmetric Links March 2001
Reducing the number of ACKs per received DATA segment has a number
of undesirable effects including:
(i) Increased path RTT
(ii) Increases the time TCP takes to open the TCP cwnd
(iii) The receiver is often unable to determine an optimum setting
(d), since it will normally be unaware of the details of the
links which form the return path.
RECOMMENDATION: Use the algorithm recommended by [RFC2581] (i.e.
d=2). Changing the algorithm requires a host modification to the
TCP protocol and awareness by the host that it is using an
asymmetric path.
5.2 Use of large MSS
If the TCP sender were to use a larger MSS, it would reduce the
number of ACKs generated per transmitted byte [RFC2488].
The problem with this approach is that most current networks do not
support arbitrarily large MTUs. Most Internet paths therefore
employ an MTU of approx 1500 B (that of Ethernet). Path MTU
discovery [RFC 1191] may be used to determine the maximum packet
size a connection can use on a given network path without being
subjected to IP fragmentation, and provides a way to automatically
use the largest MSS possible.
By electing not to use Path MTU discovery, IP fragmentation may be
used to support a larger MSS. Increasing the unit of error
recovery and congestion control (MSS) above the unit of transmission
(the IP packet) is not recommended, since it may aggravate network
congestion [Ken88].
RECOMMENDATION: IP fragmentation should not be used. A larger
forward path MTU is desirable for paths with bandwidth asymmetry.
Hosts using Path MTU discovery can take advantage of this by using a
larger MSS without requiring modification.
5.3 ACK Congestion Control
ACK congestion control (ACC) is a proposed technique which operates
end-to-end. The key idea in ACC is to extend congestion control to
TCP ACKs, since they do make non-negligible demands on resources at
the bandwidth-constrained upstream link. ACKs occupy slots in the
reverse channel buffer, whose capacity is often limited to a certain
number of packets (rather than bytes).
ACC has two parts: (a) a mechanism for the network to indicate to
the receiver that the ACK path is congested, and (b) the receiver's
response to such an indication. One possibility for the former is
the RED (Random Early Detection) algorithm [FJ93] at the upstream
bottleneck router. The router detects incipient congestion by
Expires September 2001 [page 9]
INTERNET DRAFT PILC - Asymmetric Links March 2001
tracking the average queue size over a time window in the recent
past. If the average exceeds a threshold, the router selects a
packet at random and marks it, i.e. sets an Explicit Congestion
Notification (ECN) bit in the packet header. This notification is
reflected back to the upstream TCP end-host by its downstream peer.
ACC extends the SCN scheme of IP so that both data packets and TCP
ACKs are candidates for being marked with an ECN bit. Therefore,
upon receiving an ACK packet with the ECN bit set [RFC 2481], the
TCP receiver reduces the rate at which it sends ACKs. The TCP
receiver maintains a dynamically varying delayed-ACK factor, d, and
sends one ACK for every d data packets received. When it receives a
packet with the ECN bit set, it increases d multiplicatively,
thereby decreasing the frequency of ACKs also multiplicatively. Then
for each subsequent round-trip time (determined using the TCP
timestamp option) during which it does not receive an ECN, it
linearly decreases the factor d, thereby increasing the frequency of
ACKs. Thus, the receiver mimics the standard congestion control
behavior of TCP senders in the manner in which it sends ACKs.
There are bounds on the delayed-ack factor d. Obviously, the minimum
value of d is 1, since at most one ACK should be sent per data
packet. The maximum value of d is determined by the sender's window
size, which is conveyed to the receiver in a new TCP option. The
receiver should send at least one ACK (preferably more) for each
window of data from the sender. Otherwise, it could cause the sender
to stall until the receiver's delayed-ack timer (usually set at 200
ms) kicks in and forces an ACK to be sent.
Despite RED+ECN, there may be times when the upstream router queue
fills up and it needs to drop a packet. The router can pick a packet
to drop in various ways. For instance, it can drop from the tail, or
it can drop a packet already in the queue at random.
RECOMMENDATION: ACC should not be used in its current form. Use of
ACK Congestion Control remains a research issue. Future versions of
TCP may evolve to include this or similar techniques.
5.4 Window Prediction Mechanism
The Window Prediction Mechanism (WPM) is receiver side end-to-end
solution to asymmetric paths. This scheme [CLP98] uses a dynamic ACK
delay factor resembling the ACC scheme. The receiver reconstructs
the congestion control behavior of the TCP sender by predicting a
congestion window (cwnd) value. This value is used along with the
allowed window to adjust the ACK delay factor (d). WDM accommodates
for unnecessary retransmissions resulting from losses due to link
errors.
RECOMMENDATION: This scheme is a subject of on-going research and
should not be used in its current form.
Expires September 2001 [page 10]
INTERNET DRAFT PILC - Asymmetric Links March 2001
5.5 Acknowledgement based on Cwnd Estimation.
Acknowledgement based on Cwnd Estimation (ACE)[MJW00] tries to
measure the cwnd at the receiver and maintains a varying ACK delay
factor (d). The congestion window (cwnd) is estimated by counting
the number of packets received during a path RTT. This method based
on measurements at the receiver and requires TCP receiver to be
modified. The techniques involved tries to predict cwnd more
accurately.
RECOMMENDATION: This scheme is a subject of on-going research and
should not be used in its current form.
5.6 TCP Sender Adaptation
Reducing the frequency of ACKs alleviates the problem of congestion
on the reverse bottleneck link. Each ACK potentially acknowledges
several (up to d) data packets. This can lead to problems such as
sender burstiness and a slowdown in congestion window growth.
Sender adaptation is an end-to-end technique for alleviating this. A
bound is placed on the maximum number of packets the sender can
transmit back-to-back, even if the window allows the transmission of
more data. If necessary, more bursts of data are scheduled for later
points in time computed based on the connection's data rate. The
data rate is estimated as the ratio cwnd/srtt, where cwnd is the TCP
congestion window size and srtt is the smoothed RTT estimate. Thus,
large bursts of data get broken up into smaller bursts spread out
over time.
The sender can avoid a slowdown in congestion window growth by
simply taking into account the amount of data acknowledged by each
ACK, rather than the number of ACKs. So, if an ACK acknowledges d
segments, the window is grown as if s separate ACKs had been
received. (One could treat the single ACK as being equivalent to d/2
instead of s ACKs to mimic the effect of the TCP delayed ACK
algorithm.) This policy works because the window growth is only tied
to the available bandwidth in the forward direction, so the number
of ACKs is immaterial.
RECOMMENDATION: Unlimited byte counting should not be used without a
method to mitigate the potentially large bursts of TCP data the
algorithm can cause. This is not recommended [RFC2581; RFC 2760].
Internet Draft [abc-ID] describes a restricted form of this. Use of
TCP sender pacing [AST00] is safer, but it is not widely deployed.
5.7 Backpressure and Fair Scheduling
Two techniques to address the problem of interference between data
packets and ACKs on the uplink are proposed in [KVR98]. The first
limits the number of data packets in the outgoing uplink queue by
Expires September 2001 [page 11]
INTERNET DRAFT PILC - Asymmetric Links March 2001
applying backpressure to the TCP layer. In configurations where the
uplink network adapter is directly attached to the end-system,
backpressure limits the queuing delay caused by the accumulation of
data packets at the upstream queue.
Backpressure can be unfair to the upstream connection and make its
throughput highly sensitive to the dynamics of the downstream
connection. So an alternative, fair scheduling, is proposed in
[KVR98] where a limit is placed on the number of ACKs a node is
allowed to transmit upstream before transmitting a data packet
(assuming at least one data packet is waiting in the upstream
queue). This guarantees the upstream connection at least a certain
minimum share of the bandwidth while enabling the downstream
connection to achieve high throughput.
RECOMMENDATION: Backpressure is not a standard TCP mechanism. The
modified scheme may be desirable and benefits bi-directional traffic
for hosts already using backpressure.
6. Improving TCP performance using Transparent Modifications
Various link and network layer techniques have been suggested to
mitigate the effect of the bottleneck link. These techniques may
provide benefit without modification to either the sender or
receiver, or may alternately be used in conjunction with one or more
of the schemes identified in the previous section. The techniques
are classified here based on the point at which they are introduced.
The techniques classified as type 1 and type 2 (with one exception)
require:
(i) Visibility of an unencrypted IP and TCP header
(e.g. no use of IPSEC with Payload Encryption)
(ii) Knowledge of IP/TCP options/tunnels (or ability to suspend
processing of packets with unknown formats)
(iii) Ability to demultiplex flows (by using address/protocol/port
no.).
The approach of the techniques described in this section differ from
that of a Protocol Enhancing Proxy (PEP) [PEP-ID] in that they do
NOT modify the end to end semantics, and do not inspect/modify any
TCP or UDP payload data. They also do not modify port numbers
or link addresses. Many of the risks associated with PEP also do not
exist for such schemes.
6.1 TYPE 0: Header Compression
A client may reduce the volume of ACK data by using compression.
Most modern dial-up modems support ITU-T V.42 compression. In
contrast to bulk compression, header compression is known to be very
effect at reducing the number of bits sent on a return link. This
relies on the observation that most TCP packet headers vary only in
Expires September 2001 [page 12]
INTERNET DRAFT PILC - Asymmetric Links March 2001
a few bit positions between successive packets in a flow, and that
the variations can often be predicted.
6.1.1 TCP header compression
RFC 1144 [RFC 1144] (sometimes known as V-J compression) describes
TCP header compression for use over low-bandwidth links running SLIP
or PPP. Because it greatly reduces the size of ACKs on the reverse
link when losses are infrequent (a situation that ensures that the
state of the compressor and decompressor are synchronized), we
recommend its use over low-bandwidth reverse links where possible.
However, this alone does not address all of the problems:
1. In some (e.g. wireless) networks there is a significant per-
packet MAC overhead that is independent of packet size.
2. A reduction in the size of ACKs does not prevent adverse
interaction with large upstream data packets in the presence of
bi-directional traffic (discussed in Section 4.3).
3. TCP header compression may not be used with packets which have IP
or TCP options (including IPSEC, TCP RTTM, TCP SACK, etc.)
4. The performance of header compression described by RFC1144 is
significantly degraded when packets are lost. This therefore
suggests the scheme should only be used on links which see a low
level of packet loss.
5. The normal implementation of Header Compression inhibits
compression when IP is used as a tunneling e.g. L2TP, GRE, IP-in-
IP). The tunnel encapsulation complicates locating the
appropriate packet headers. Although GRE allows Header
Compression on the inner (tunneled) IP header [RFC2784], this is
not recommended, since loss of a packet (e.g. to router
congestion along the tunnel path) will result in discard of all
packets for one RTT [RFC1144].
RECOMMENDATION: This technique benefits paths which have a low-to-
medium bandwidth asymmetry. The scheme is widely implemented and
deployed, but in the form described in [RFC 1144] should not used
over paths which may exhibit appreciable rates of packet loss. The
scheme on its own does not provide significant improvement for links
with bi-directional traffic.
6.1.2 Alternate Robust Header Compression Algorithms
As discussed previously, VJ Header compression [RFC 1144] and IP
header compression [RFC 2507] do not perform well in error prone
links. Further they do not compress packets with TCP option fields
such as SACK and Timestamp (RTTM). However, recent work on more
robust schemes suggest that a new generation of compression
algorithms may be developed which are much more robust. The ROHC
Work Group [rohc] in IETF is working on specifying different header
compression schemes:
(i) To work well over lossy links
Expires September 2001 [page 13]
INTERNET DRAFT PILC - Asymmetric Links March 2001
(ii) To work well over long delay paths
(iii) Able to compress over unidirectional links
(iv) Support both IPv4 and IPv6 and various transport protocols
(e.g. TCP, UDP, RTP)
The work in progress of this working may be beneficial to asymmetric
networks.
RECOMMENDATION: Robust header compression techniques benefit paths
which have a low-to-medium bandwidth asymmetry and may be robust to
packet loss. The scheme on its own does not provide significant
improvement in asymmetric networks with bi-directional traffic.
6.2 TYPE 1: Reverse Link Bandwidth Management
To effectively address the performance problems caused by asymmetry,
there is a need for techniques over and beyond TCP header
compression. The second type of techniques are performed only at
one point on the return path, within the upstream router/host. It
uses class or per-flow queues at the upstream interface of the
router/host to manage the queue of packets waiting for transmission
on the bottleneck return link.
In this type of technique, the queue size is bounded, and an
algorithm employed to remove (discard) excess ACK packets from each
queue. Like the host modification to increase ACK delay (d>2), this
relies on the cumulative nature of TCP ACKs.
6.2.1 ACK Filtering
ACK filtering (AF) [DMT96, BPK97] (also known as ACK Suppression
[SF98, Sam99, FSS01]) is a TCP-aware link-layer technique that
reduces the number of TCP ACKs sent on the reverse channel. The
challenge is to ensure that the sender does not stall waiting for
ACKs, which can happen if ACKs are removed indiscriminately on the
reverse path. AF removes only certain ACKs without starving the
sender by taking advantage of the fact that TCP ACKs are cumulative.
As far as the sender's error control mechanism is concerned, the
information contained in an ACK with a later sequence number
subsumes the information contained in any earlier ACK.
When an ACK from the receiver is about to be enqueued at a reverse
direction router, the router or the end-host's link layer (if the
host is directly connected to the bottleneck upstream link) checks
its queues for any older ACKs belonging to the same connection. If
any are found, it removes them from the queue, thereby reducing the
number of ACKs that go back to the sender. The removal of these
"redundant" ACKs frees up buffer space for other data and ACK
packets.
Expires September 2001 [page 14]
INTERNET DRAFT PILC - Asymmetric Links March 2001
Some ACKs also have other functions in TCP [RFC1144], and must not
be deleted to ensure normal operation. AF must therefore not delete
an ACK which has any DATA or TCP flags set (sync, reset, urgent, and
final). In addition, the suppressor should avoid deleting a series
of 3 duplicate ACKs which indicate the need for Fast Retransmission
[RFC2581] or selective ACKs from the queue to avoid causing problems
to TCP's data-driven loss recovery mechanisms.
The policy that the filter uses to drop packets may be configured
and either is deterministic or random (similar to a random-drop
gateway, but taking the semantics of the items in the queue into
consideration). Algorithms have also been suggested to ensure a
minimum ACK rate to guarantee the sender's window is updated [Sam99,
FSS01]. State needs to be maintained only for connections with at
least one packet in the queue (akin to FRED [LM97]). However, this
state is soft, and if necessary, can easily be reconstructed from
the contents of the queue.
RECOMMENDATION: This technique benefits paths which have an
arbitrary bandwidth asymmetry. The scheme has been deployed in
specific production networks (e.g. asymmetric satellite networks
[ASB96]). The extra processing overhead (per ACK) required may be
compensated for by avoiding the need to modify TCP. However, at
high asymmetry (or with bi-directional traffic) the scheme may
increase the burstiness of the TCP sender.
6.2.2 ACK Decimation
ACK Decimation is based on standard router mechanisms. By using an
appropriate configuration of (small) per-flow queues and a chosen
dropping policy (e.g. WFQ), a similar effect to ACK filtering may be
obtained, but with less control of the actual packets which are
dropped.
In this scheme, the router/host at the bottleneck upstream link
maintains per-flow queues and services them fairly (or with
priorities) by handling the queuing and scheduling of ACKs and DATA
in the reverse direction. A small queue threshold is maintained to
drop the excessive ACKs from the tail, in order to reduce ACK
congestion. The inability to identify the special ACK packets (c.f.
AF) introduces some major drawbacks to this approach such as the
possibility of losing duplicate acknowledgements and FIN/ACK
packets.
This technique has been deployed in a military network, which shows
high bandwidth asymmetry to support high-speed data services to
in-transit mobile nodes and shipboard [Seg00]. It has proven to be
workable, resulting significant performance improvement for
asymmetric transfers (although not optimal). It also offers a
potential mitigation which may be applicable even when the TCP
header is no longer visible (due to IPSEC encryption).
Expires September 2001 [page 15]
INTERNET DRAFT PILC - Asymmetric Links March 2001
A WFQ scheduler may assign a higher priority to interactive traffic
and provide a fair share of the remaining bandwidth to the data
traffic. In the presence of bi-directional traffic, this scheme may
ensure fairer sharing for ACK and DATA packets. In such a case
forward data rate is maintained by increased ACK decimation rate.
Sender burstiness resulting from stretched ACKs is a side effect in
ACK decimation approach (as for ACK filtering).
RECOMMENDATION: This technique uses standard router mechanisms to
constrain the rate at which ACKs are fed to the upstream bottleneck
link, and has been deployed on at least one network. The approach
is sub optimal, in that it may lead to inefficient TCP error
recovery, and provides only crude control of the link behavior. At
high asymmetry (or with bi-directional traffic) the scheme may
increase the burstiness of the TCP sender.
6.3 TYPE 2: Handling Infrequent ACKs
TYPE 2 mitigations perform TYPE 1 return link bandwidth management,
but also employ a second active element which mitigates the effect
of the reduced ACK rate and bursty transmission. The aim is to
reduce the impact of culmulative ACKs (sometimes called _stretched
ACKs_) on TCP self clocking.
The action is performed at two points on the return path (the
bottleneck uplink transmit interface (where excess ACKs are
removed), and a point further along the return path, after the
bottleneck uplink link(s)) where replacement ACKs are inserted. Such
schemes need to ensure conservative behaviour (should never
introduce more ACKs than were originally sent) and reduce the
probability of ACK Compression.
TYPE 2 mitigations can be performed locally at the constrained
reverse link, or may alternatively be applied at any place along the
reverse path.
6.3.1 ACK Reconstruction
ACK Reconstruction (AR) is a technique to reconstruct the ACK stream
after it has traversed the upstream bottleneck link. AR is a local
technique designed to prevent the reduced ACK frequency from
adversely affecting the performance of standard TCP sender
implementations (i.e., those that do not implement sender
adaptation). This enables schemes such as ACK filtering or ACK
congestion control to be used without requiring TCP senders to be
modified to perform sender adaptation. This solution can be easily
deployed by Internet Service Providers (ISPs) of asymmetric access
technologies in conjunction with AF to achieve good performance.
AR deploys a soft-state agent called the ACK reconstructor at the
upstream end of the constrained ACK bottleneck. The reconstructor
Expires September 2001 [page 16]
INTERNET DRAFT PILC - Asymmetric Links March 2001
does not need to be on the forward data path, but must be on the
reverse path. It fills in the gaps in the ACK sequence (by using an
algorithm to estimate the number of filtered ACKs) and introduces
ACKs to smooth out the ACK stream seen by the sender. However, it
does so without violating the end-to-end semantics of TCP ACKs, as
explained below.
Suppose two ACKs, a1 and a2 arrive at the reconstructor after
traversing the constrained upstream link at times t1 and t2
respectively. Let a2 - a1 = delta_a > 1. If a2 were to reach the
sender soon after a1 with no intervening ACKs, at least delta_a
segments are burst out by the sender (if the flow control window is
large enough), and the congestion window increases by at most 1,
independent of delta_a. ACK reconstruction remedies this problematic
situation by interspersing ACKs to provide the sender with a larger
number of ACKs at a consistent rate, which reduces the degree of
burstiness and causes the congestion window to increase at a rate
governed by the forward bottleneck.
One of the configurable parameters of the reconstructor is
ack_thresh, the ACK threshold, which determines the spacing between
interspersed ACKs at the output. Typically, ack_thresh is set to 2,
which follows TCP's standard delayed-ACK policy. Thus, if successive
ACKs arrive at the reconstructor separated by delta_a, it interposes
ceil (delta_a/ack_thresh) - 2 ACKs, where ceil() is the ceiling
operator. The other parameter needed by the reconstructor is
ack_interval, which determines the temporal spacing between the
reconstructed ACKs. To do this, it measures the rate at which ACKs
arrive at the input to the reconstructor. This rate depends on the
output rate from the constrained reverse channel and on the presence
of other traffic on that link. The reconstructor uses an
exponentially weighted moving average estimator to monitor this
rate; the output of the estimator is delta_t, the average temporal
spacing at which ACKs are arriving at the reconstructor (and the
average rate at which ACKs would reach the sender if there were no
further losses or delays).
If the reconstructor sets ack_interval equal to delta_t, then we
would essentially operate at a rate governed by the reverse
bottleneck link, and the resulting performance would be determined
by the rate at which unfiltered ACKs arrive out of the reverse
bottleneck link. If sender adaptation were being done, then the
sender behaves as if the rate at which acks arrive us
delta_a/delta_t.
Therefore, a suitable method of deciding the temporal spacing of
reconstructed ACKs, ack_interval, is to equate the rates at which
increments in the ACK sequence happen in the two cases. That is, the
reconstructor sets ack_interval such that delta_a/delta_t =
ack_thresh/ack_interval, which implies that ack_interval =
(ack_thresh/delta_a)*delta_t. Therefore, the latest ACK in current
sequence, a2, is held back for a time roughly equal to delta_t, and
ceil(delta_a/ack_thresh) - 2 ACKs are evenly interposed in this
time. Thus, by controlling the number of and spacing between ACKs,
Expires September 2001 [page 17]
INTERNET DRAFT PILC - Asymmetric Links March 2001
unmodified TCP senders can be made to increase their congestion
window at an acceptable rate and avoid bursty behavior. ACK
reconstruction can be implemented by maintaining only "soft state"
[Clark88] at the reconstructor that can easily be regenerated if
lost.
Providing the TCP receiver uses ACK delay (d=2), the reconstructor
receives in-order ACKs, and all ACK packets are routed via the
reconstructor, it generates no spurious ACKs and the end-to-end
semantics of the connection are completely preserved. The trade-off
in AR is between obtaining less bursty performance, a better rate of
congestion window increase, and a reduction in the round-trip
variation, versus a modest increase in the round-trip time estimate
at the sender. We believe that it is a good trade-off in the
asymmetric environments we are concerned with.
RECOMMENDATION: ACK Reconstruction reduces the burstiness of TCP
transmission which may otherwise arise when ACK Filtering alone is
used. The scheme is desirable, but requires modification of
equipment after the bottleneck return link. Selection of appropriate
algorithms to pace the ACK traffic remains an open research issue.
6.3.2 ACK Compaction/Companding
ACK Compaction [SAM99, FSS01] is a scheme which normally relies upon
the presence of a tunnel to a remote expander (located along the
return path, for instance co-located with the feed router in a UDLR
network [udlr]). It uses AF with two modifications: First, when
the compressor deletes an ACK from the transmit queue, it appends
information to the remaining ACK (this ACK is marked to ensure it is
not subsequently deleted). The additional information contains
explicit information which details the conditions under which the
excess ACKs were deleted. In AR, the ACK stream is reconstructed
using implicit information inferred from the header of the received
ACKs, whereas in ACK Compaction, the ACK stream is reconstructed
using explicit information sent with the compacted ACK.
A variety of information may be encoded in the compacted ACK. This
includes the (explicit) number of ACKs deleted by the AF and the
average number of bytes acknowledged. This is subsequently used by
an expander at the remote end of the tunnel. Further timing
information may also be added to configure the pacing algorithm
[FSS01].
To encode the extra information requires that the Expander
recognises a modified ACK header. This would normally limit the
Expander to link local operation (as in AR). A tunnel may be used
to pass the modified ACKs to an Expander along the return path.
Since the Expander generates ACKs upon reception of each Compacted
ACK, it is recommended that the Expander implements a scheme to
prevent exploitation in Denial of Service (DoS) attacks (e.g. to
Expires September 2001 [page 18]
INTERNET DRAFT PILC - Asymmetric Links March 2001
verify the originator of the compacted ACK). This could be
accomplished by packet filters or by tunnel encryption procedures.
ACK Expansion uses a stateless algorithm (i.e. each received packet
is processed independently of previously received packets) to expand
the ACK. It uses the prefixed information together with the
acknowledgment field in the received ACK, to produce an equivalent
number of ACKs to those previously deleted by the compactor. These
ACKs are forwarded to the original destination (i.e. the TCP
sender), preserving normal TCP ACK clocking. In this way, ACK
Compaction, unlike AR, is not reliant on specific ACK policies (e.g.
it may be compatible with schemes such as DAASS [RFC2760]).
Other techniques similar in vein to ACK Compaction has also been
proposed [JSK99]. An ACK compressor concatenates multiple ACKs and
sends them to the decompressor together with the arrival time of the
concatenated ACKs into the queue. The decompressor then uses this
information to regenerate the individual ACKs. Like the ACK
compacter/expander, this scheme enables more accurate regeneration
of ACKs compared to AF/AR.
RECOMMENDATION: ACK Compaction is an item of on-going research. The
scheme reduces the burstiness of TCP transmission which may
otherwise arise when ACK Filtering alone is used. Like AR, the
scheme is desirable, but requires modification of additional
protocol machinery after the bottleneck return link, and the use of
a tunnel (if the expander is not directly connected to the receiver
of the bottleneck link). The technique has not, at the time of
writing been widely deployed.
6.3.3 Mitigating the Effect of Infrequent ACKs
The bursts of DATA packets generated when AF (and other related
techniques are employed) may be undesirable. Such bursts may lead
to congestion loss on the forward path, and increase the jitter
experienced by other sessions sharing the forward path. Various
techniques to mitigate these effects have already been discussed
(TCP sender pacing, ACK Reconstruction and ACK Compaction). Another
way to reduce the impact of these bursts is to employ Generic
Traffic Shaping (GTS)on the forward path [Seg00].
6.4 TYPE 3: Uplink Scheduling
Many of the above schemes imply per flow queues. Per-flow queuing
(e.g. FQ, CBQ) does offer some benefit even when used on links which
do not provide other forms of mitigations, but offers additional
benefit when used with one of the above techniques.
Expires September 2001 [page 19]
INTERNET DRAFT PILC - Asymmetric Links March 2001
6.4.1 Per-Flow queuing on the upstream bottleneck link
When bi-directional traffic exists in a bandwidth asymmetric network
competing ACK and data traffic in the return path may degrade the
performance both downstream and down stream flows [KVR98].
Therefore, it is highly desirable to use a queuing strategy combined
with a scheduling mechanism at the return path.
A simple scheme can be implemented using a per-flow queuing with a
fair scheduler (e.g. simple round robin service to all flows or
priority scheduling). A smaller MTU may be used to mitigate the
impact (jitter) of bi-directional traffic on low speed links, More
advanced schemes (e.g. WFQ) may also be used to improve the
performance of transfers with multiple Acknowledgement streams such
as p-http.[Seg00].
On a slow uplink, appreciable jitter may be introduced by sending
large DATA packets ahead of ACKs. One way of reducing the delay is
to use transparent link fragmentation to fragment the data packet
into small pieces before transmission [RFC1990, RFC2686].
RECOMMENDATION: Per-flow (or per-class) scheduling is widely
implemented and widely deployed. The scheme has particular benefits
for slow links. It is recommended as a mitigation on its own or in
combination with one of the other techniques outlined here.
6.4.2 ACKs-first Scheduling
In the case of bi-directional transfers, data as well as ACK packets
compete for resources in the reverse direction. In this case, a
single FIFO queue for both data packets and ACKs could cause prob-
lems. For example, if the reverse channel is a 28.8 Kbps dialup
line, the transmission of a 1 KB sized data packet would take about
280 ms. So even if just two such data packets get queued ahead of
ACKs (not an uncommon occurrence since data packets are sent out in
pairs during slow start), they would shut out ACKs for well over
half a second. And if more than two data packets are queued up ahead
of an ACK, the ACKs would be delayed by even more.
A possible approach to alleviating this problem is to schedule data
and ACKs differently from FIFO. One algorithm, in particular, is
ACKs-first scheduling, which always accords a higher priority to
ACKs over DATA packets. The motivation for such scheduling is that
it minimizes the idle time for the forward connection by minimizing
the amount of time that its ACKs spend queued behind upstream data
packets. At the same time, with techniques such as header
compression [RFC1144], the transmission time of ACKs becomes small
enough that its impact on subsequent DATA packets is minimal.
(Networks in which the per-packet overhead of the reverse channel is
large, e.g. packet radio networks, are an exception.) This
scheduling scheme does not require the upstream bottleneck
router/host to explicitly identify or maintain state for individual
TCP connections.
Expires September 2001 [page 20]
INTERNET DRAFT PILC - Asymmetric Links March 2001
ACKs-first scheduling does not help avoid a delay due to a data
packet in transmission. Link fragmentation may be beneficial in
this case.
RECOMMENDATION: If the ACKs-first scheduling is used without a
mechanism (such as ACK congestion control (ACC)) to regulate the
volume of ACKs, it could lead to starvation of DATA packets.
Experiments indicate that ACKs-first scheduling in combination with
ACC is promising. However, further development of the technique
remains an open research issue.
7. Security Considerations
Security considerations in the context of this Internet Draft arise
primarily from the possible use of IPSEC by the end hosts:
1. With IPSEC ESP, the TCP header can neither be read nor modified
by intermediate entities. This rules out header compression, ACK
filtering, and ACK reconstruction.
2. With IPSEC AH or TF-ESP, the TCP header can be read but not
modified by intermediaries. This rules out ACK reconstruction but
allows ACK filtering. The enhanced header compression scheme
discussed in [RFC2505] would also work with AH.
There are potential DoS implications when using Type 2 schemes with
a return path tunnel. The usual precautions must be taken to verify
the correct tunnel end point, and to ensure that applications cannot
falsely inject compressed packets which expand to generate unwanted
traffic.
8. Summary
This Internet Draft considers several TCP performance constraints
that arise from asymmetry in network links and surveys several
possible mitigations. Performance limitations arise as a result of
asymmetry in both bandwidth and interactions with media-access
control protocols.
Asymmetric bandwidth provision may cause TCP ACKs to be lost or
become inordinately delayed (e.g., when there is bi-directional
traffic. This effect may be exacerbated with media-access delays
(e.g., in certain multi-hop radio networks, satellite BoD access).
TCP header compression, while being helpful, does not necessarily
address many of these issues.
This Internet Draft surveys performance improvement techniques that
combine ACK congestion alleviation with techniques that enable a TCP
sender to cope with infrequent ACKs without destroying its self-
clocking. These techniques include both end-to-end and local link-
layer schemes. Many of these techniques have been evaluated in
detail via analysis, simulation, and/or implementation on real
asymmetric networks.
Expires September 2001 [page 21]
INTERNET DRAFT PILC - Asymmetric Links March 2001
The techniques proposed in this document differ from those used in
Protocol Enhancing Proxies (PEP) in that they do NOT seek to modify
the end to end semantics, and do not inspect/modify any TCP or UDP
payload data. They also do not modify port numbers or line
addresses. Many of the risks associated with PEP do not exist for
such schemes.
9. References
[abc-ID] M Allman, draft-allman-tcp-abc-00.txt, Internet Draft, WORK
IN PROGRESS.
[ASB96]V. Arora, N. Suphasindhu, J.S. Baras, D. Dillon _ Asymmetric
Internet Access over Satellite-Terrestrial Networks_, Proceedings of
the AIAA: 16th International Communications Satellite Systems
Conference and Exhibit, Part 1, pp.476-482, Washington, D.C.,
February 25-29, 1996.
[AST00] Amit Aggarwal, Stefan Savage, and Tom Anderson,
_Understanding the Performance of TCP Pacing,_ Proc. of IEEE
Infocom, Tel-Aviv, Israel, 2000.
[Bal98] H. Balakrishnan, "Challenges to Reliable Data Transport over
Heterogeneous Wireless Networks", Ph.D. Thesis, University of
California at Berkeley, USA, August 1998.
http://www.cs.berkeley.edu/~hari/thesis/
[BPK97] H. Balakrishnan, V. N. Padmanabhan, R. H. Katz, "The Effects
of Asymmetry on TCP Performance", Proc. ACM/IEEE Mobicom, Budapest,
Hungary, September 1997.
[BPK99] H. Balakrishnan, V. N. Padmanabhan, R. H. Katz, "The Effects
of Asymmetry on TCP Performance", ACM Mobile Networks and
Applications (MONET), 1999. This is an expanded journal version of
the Mobicom '97 paper.
[CLC99]H Clausen, H Linder, and B Collini-Nocker, _Internet over
Broadcast Satellites_. IEEE Commun. Mag. 1999.pp. 146-151.
[CLP98] A. Calveras, J. Linares, J. Paradells. _Window Prediction
Mechanism for Improving TCP in Wireless Asymmetric Links_.
Globecom'98. Sydney Australia. November 1998.
[CR98] R. Cohen, S. Ramanathan, "TCP for High Performance in Hybrid
Fiber Coaxial Broad-Band Access Networks", IEEE/ACM Transactions on
Networking, February 1998.
[DMT96] R. Durst, G. Miller, and E. Travis, (1996). "TCP Extensions
for Space Communications," 2nd ACM International Conference on
Mobile Computing and Networking (Mobicom), November, pp. 15-26.
Expires September 2001 [page 22]
INTERNET DRAFT PILC - Asymmetric Links March 2001
[FJ93] Floyd, S., Jacobson, V., "Random Early Detection gateways for
Congestion Avoidance", IEEE/ACM ToN, V.1, N.4, August 1993, p.397-
413.
[FSS01] G. Fairhurst, N. K. G. Samaraweera, M. Sooriyabandara, H.
Harun, K. Hodson, and R. Donardio, _Performance Issues in Asymmetric
Service Provision using Broadband Satellite_, IEE Proceedings-
Communications, 2001.
[Jac88] V. Jacobson, Congestion Avoidance and Control, Proc. ACM
SIGCOMM, Stanford, CA, August 1988.
[JSK99] Johansson G.L, Shakargi, H. Kanljung, C. Kullander, J.
_ACKNOWLEDGEMENT Compression Rev B_, Technical Report December 1999.
[Ken88]C. A. Kent and J. C. Mogul, "Fragmentation Considered
Harmful," presented at SIGCOMM, USA, 1988.
[KSG98] Krout, T., Solsman, M., Goldstein, J., 'The effects of
Asymmetric Satellite Networks on Protocols', MilCom98, Bradford, MA.
[KVR98] L. Kalampoukas, A. Varma, K. K. Ramakrishnan, "Improving TCP
Throughput over Two-Way Asymmetric Links: Analysis and Solutions",
Proc. ACM SIGMETRICS, June 1998.
[LM97] D. Lin, R. Morris, "Dynamics of Random Early Detection",
Proc. ACM SIGCOMM, 1997.
[LMS97] T. V. Lakshman, U. Madhow, B. Suter, "Window-based Error
Recovery and Flow Control with a Slow Acknowledgement Channel: A
Study of TCP/IP Performance", Proc. IEEE Infocom, Kobe, Japan, April
1997.
[Met] Metricom Inc., http://www.metricom.com
[MJW00] Ming-Chit, I.T, Jinsong, D. Wang, W. "Improving TCP
Performance Over Asymmetric Networks" ACM SIGCOMM CCR, July 2000.
[Pad98] V. N. Padmanabhan, "Addressing the Challenges of Web Data
Transport", Ph.D. Thesis, University of California at Berkeley, USA,
September 1998 (also Tech Report UCB/CSD-98-1016).
http://www.research.microsoft.com/~padmanab/phd-thesis.html
[PEP-ID] J. Border draft-ietf-pilc-pep-05.txt, Internet Draft, WORK
IN PROGRESS.
[RFC 2581] M. Allman, V. Paxson, W. Stevens, _TCP Congestion
Control_, RFC 2581.
[RFC1144] V. Jacobson, "Compressing TCP/IP Headers for Low-Speed
Serial Links", RFC-1144, February 1990.
Expires September 2001 [page 23]
INTERNET DRAFT PILC - Asymmetric Links March 2001
[RFC1990] K. Sklower, B. Lloyd, G. McGregor, D. Carr, T. Coradetti,
"The PPP Multilink Protocol (MP)", RFC-1990, August 1996.
[RFC2026] S. Bradner, "The Internet Standards Process -- Revision
3", RFC-2026, October 1996.
[RFC2119] S. Bradner, " Key words for use in RFCs to Indicate
Requirement Levels", RFC-2119, March 1997.
[RFC2481] K. Ramakrishnan and S. Floyd, "A Proposal to add
Explicit Congestion Notification (ECN) to IP," IETF, Experimental
RFC2481, January 1999.
[RFC2505] M. Degermark, B. Nordgren, S. Pink, "IP Header
Compression", RFC-2507, February 1999.
[RFC2507] Degermark, M. Nordgren, B. Pink, S. IP Header Compression.
Internet Engineering Task Force, Feb.1999. RFC-2507.
[RFC2686] C. Bormann, "The Multi-Class Extension to Multi-Link PPP",
RFC-2686, September 1999.
[rohc] Robust Header Compression Working Group IETF,
http://www.ietf.org/html.charters/rohc-charter.html.
[Sam99] N. K. G. Samaraweera, "Return Link Optimization for Internet
Service Provision Using DVB-S Networks", ACM SIGCOMM CCR, July 1999.
[Seg00] R. Segura " Asymmetric Networking Techniques For Hybrid
Satellite Communications" NC3A, Technical Note 810. August 2000.
[SF98] N Samaraweera, G Fairhurst. _High Speed Internet Access using
Satellite-based DVB Networks_, International Networks Conference.
Plymouth, UK 1998, IEEE. pp 23-28.
[udlr] UniDirectional Link Routing Working Group, IETF,
http://www.ietf.org/html.charters/udlr-charter.html.
[ZSC91] L. Zhang, S. Shenker, and D. D. Clark, Observations and
Dynamics of a Congestion Control Algorithm: The Effects of Two-Way
Traffic. In Proc. ACM SIGCOMM '91, pages 133--147, 1991
10. Acknowledgments
We thank Spencer Dawkins, Aaron Falk, and the members of the PILC
mailing list for their valuable comments.
Expires September 2001 [page 24]
INTERNET DRAFT PILC - Asymmetric Links March 2001
11. Appendix A: Known Areas of Future Research
Operation with IP flows using IPSEC with Authentication.
Type 0 schemes must transport the additional security
information
Type 1 schemes may be adapted to support this.
Type 2 schemes are unable to "regenerate" ACKs unless
the additional security information is also sent.
ACK Regeneration by a middle party may also have
other security implications (???).
Most current schemes pass all IPSEC packets without
change/enhancement.
Operation with TCP-ECN
Type 0-2 schemes may in future be modified to
support use of ECN.
Most current schemes will pass all TCP-ECN packets
without change/enhancement.
Operation with TCP-SACK and TCP-DSACK
Type 0 schemes must transport the additional SACK
information
Type 1 schemes may be adapted to support this, but
suppression may be less effective.
Type 2 schemes must be able to "regenerate" SACK packets,
but will require additional SACK information to also be sent.
Most current schemes pass all TCP SACK packets without
change/enhancement.
12. Authors' Addresses
Hari Balakrishnan
Laboratory for Computer Science
200 Technology Square
Massachusetts Institute of Technology
Cambridge, MA 02139
USA
Phone: +1-617-253-8713
Fax: +1-617-253-0147
Email: hari@lcs.mit.edu
Web: http://nms.lcs.mit.edu/~hari/
Venkata N. Padmanabhan
Microsoft Research
One Microsoft Way
Redmond, WA 98052
USA
Phone: +1-425-705-2790
Fax: +1-425-936-7329
Email: padmanab@microsoft.com
Web: http://www.research.microsoft.com/~padmanab/
Expires September 2001 [page 25]
INTERNET DRAFT PILC - Asymmetric Links March 2001
Godred Fairhurst
Department of Engineering
Fraser Noble Building
University of Aberdeen
Aberdeen AB24 3UE
UK
Phone: +44-1224-272201
Fax: +44-1224-272497
Email: gorry@erg.abdn.ac.uk
Web: http://www.erg.abdn.ac.uk/users/gorry
Mahesh Sooriyabandara
Department of Engineering
Fraser Noble Building
University of Aberdeen
Aberdeen AB24 3UE
UK
Phone: +44-1224-272780
Fax: +44-1224-272497
Email: mahesh@erg.abdn.ac.uk
Web: http://www.erg.abdn.ac.uk/users/mahesh
Expires September 2001 [page 26]
INTERNET DRAFT PILC - Asymmetric Links March 2001
Full Copyright Statement
"Copyright (C) The Internet Society (date). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
Expires September 2001 [page 27]
