evidence that such a policy may be difficult to incrementally deploy
in an operational network. The proper selection of a constant (for
the constant rate of increase) is an open issue.
The "Increase-by-K" policy can be selectively used by long RTT
connections in a heterogeneous environment. This policy simply
changes the slope of the linear increase, with connections over a
given RTT threshold adding "K" segments to the congestion window
every RTT, instead of one. [HK98] presents evidence that this
policy, when used with small values of "K", may be successful in
reducing the unfairness while keeping the link utilization high, when
a small number of connections share a bottleneck link. The selection
of the constant "K," the RTT threshold to invoke this policy, and
performance under a large number of flows are all open issues.
3.4.3 Implementation Issues
Implementation of either the "Constant-Rate" or "Increase-by-K"
policies requires a change to the congestion avoidance mechanism at
the TCP sender. In the case of "Constant-Rate," such a change must
be implemented globally. Additionally, the TCP sender must have a
reasonably accurate estimate of the RTT of the connection. The
algorithms outlined above violate the congestion avoidance algorithm
as outlined in RFC2581 [APS99] and therefore should not be
implemented in shared networks at this time.
3.4.4 Topology Considerations
These solutions are applicable to all satellite networks that are
integrated with a terrestrial network, in which satellite connections
may be competing with terrestrial connections for the same bottleneck
link.
3.4.5 Possible Interaction and Relationships with Other Research
As shown in [PADHV99], increasing the congestion window by multiple
segments per RTT can cause TCP to drop multiple segments and force a
retransmission timeout in some versions of TCP. Therefore, the above
changes to the congestion avoidance algorithm may need to be
accompanied by a SACK-based loss recovery algorithm that can quickly
repair multiple dropped segments.
3.5 Multiple Data Connections
3.5.1 Mitigation Description
One method that has been used to overcome TCP's inefficiencies in the
satellite environment is to use multiple TCP flows to transfer a
given file. The use of N TCP connections makes the sender N times
more aggressive and therefore can improve throughput in some
situations. Using N multiple TCP connections can impact the transfer
and the network in a number of ways, which are listed below.
1. The transfer is able to start transmission using an effective
congestion window of N segments, rather than a single segment as
one TCP flow uses. This allows the transfer to more quickly
increase the effective cwnd size to an appropriate size for the
given network. However, in some circumstances an initial window
of N segments is inappropriate for the network conditions. In
this case, a transfer utilizing more than one connection may
aggravate congestion.
2. During the congestion avoidance phase, the transfer increases the
effective cwnd by N segments per RTT, rather than the one segment
per RTT increase that a single TCP connection provides. Again,
this can aid the transfer by more rapidly increasing the effective
cwnd to an appropriate point. However, this rate of increase can
also be too aggressive for the network conditions. In this case,
the use of multiple data connections can aggravate congestion in
the network.
3. Using multiple connections can provide a very large overall
congestion window. This can be an advantage for TCP
implementations that do not support the TCP window scaling
extension [JBB92]. However, the aggregate cwnd size across all N
connections is equivalent to using a TCP implementation that
supports large windows.
4. The overall cwnd decrease in the face of dropped segments is
reduced when using N parallel connections. A single TCP
connection reduces the effective size of cwnd to half when a
single segment loss is detected. When utilizing N connections
each using a window of W bytes, a single drop reduces the window
to:
(N * W) - (W / 2)
Clearly this is a less dramatic reduction in the effective cwnd size
than when using a single TCP connection. And, the amount by which
the cwnd is decreased is further reduced by increasing N.
The use of multiple data connections can increase the ability of
non-SACK TCP implementations to quickly recover from multiple dropped
segments without resorting to a timeout, assuming the dropped
segments cross connections.
The use of multiple parallel connections makes TCP overly aggressive
for many environments and can contribute to congestive collapse in
shared networks [FF99]. The advantages provided by using multiple
TCP connections are now largely provided by TCP extensions (larger
windows, SACKs, etc.). Therefore, the use of a single TCP connection
is more "network friendly" than using multiple parallel connections.
However, using multiple parallel TCP connections may provide
performance improvement in private networks.
3.5.2 Research
Research on the use of multiple parallel TCP connections shows
improved performance [IL92,Hah94,AOK95,AKO96]. In addition, research
has shown that multiple TCP connections can outperform a single
modern TCP connection (with large windows and SACK) [AHKO97].
However, these studies did not consider the impact of using multiple
TCP connections on competing traffic. [FF99] argues that using
multiple simultaneous connections to transfer a given file may lead
to congestive collapse in shared networks.
3.5.3 Implementation Issues
To utilize multiple parallel TCP connections a client application and
the corresponding server must be customized. As outlined in [FF99]
using multiple parallel TCP connections is not safe (from a
congestion control perspective) in shared networks and should not be
used.
3.5.4 Topological Considerations
As stated above, [FF99] outlines that the use of multiple parallel
connections in a shared network, such as the Internet, may lead to
congestive collapse. However, the use of multiple connections may be
safe and beneficial in private networks. The specific topology being
used will dictate the number of parallel connections required. Some
work has been done to determine the appropriate number of connections
on the fly [AKO96], but such a mechanism is far from complete.
3.5.5 Possible Interaction and Relationships with Other Research
Using multiple concurrent TCP connections enables use of a large
congestion window, much like the TCP window scaling option [JBB92].
In addition, a larger initial congestion window is achieved, similar
to using [AFP98] or TCB sharing (see section 3.8).
3.6 Pacing TCP Segments
3.6.1 Mitigation Description
Slow-start takes several round trips to fully open the TCP congestion
window over routes with high bandwidth-delay products. For short TCP
connections (such as WWW traffic with HTTP/1.0), the slow-start
overhead can preclude effective use of the high-bandwidth satellite
links. When senders implement slow-start restart after a TCP
connection goes idle (suggested by Jacobson and Karels [JK92]),
performance is reduced in long-lived (but bursty) connections (such
as HTTP/1.1, which uses persistent TCP connections to transfer
multiple WWW page elements) [Hei97a].
Rate-based pacing (RBP) is a technique, used in the absence of
incoming ACKs, where the data sender temporarily paces TCP segments
at a given rate to restart the ACK clock. Upon receipt of the first
ACK, pacing is discontinued and normal TCP ACK clocking resumes. The
pacing rate may either be known from recent traffic estimates (when
restarting an idle connection or from recent prior connections), or
may be known through external means (perhaps in a point-to-point or
point-to-multipoint satellite network where available bandwidth can
be assumed to be large).
In addition, pacing data during the first RTT of a transfer may allow
TCP to make effective use of high bandwidth-delay links even for
short transfers. However, in order to pace segments during the first
RTT a TCP will have to be using a non-standard initial congestion
window and a new mechanism to pace outgoing segments rather than send
them back-to-back. Determining an appropriate size for the initial
cwnd is an open research question. Pacing can also be used to reduce
bursts in general (due to buggy TCPs or byte counting, see section
3.2.2 for a discussion on byte counting).
3.6.2 Research
Simulation studies of rate-paced pacing for WWW-like traffic have
shown reductions in router congestion and drop rates [VH97a]. In
this environment, RBP substantially improves performance compared to
slow-start-after-idle for intermittent senders, and it slightly
improves performance over burst-full-cwnd-after-idle (because of
drops) [VH98]. More recently, pacing has been suggested to eliminate
burstiness in networks with ACK filtering [BPK97].
3.6.3 Implementation Issues
RBP requires only sender-side changes to TCP. Prototype
implementations of RBP are available [VH97b]. RBP requires an
additional sender timer for pacing. The overhead of timer-driven
data transfer is often considered too high for practical use.
Preliminary experiments suggest that in RBP this overhead is minimal
because RBP only requires this timer for one RTT of transmission
[VH98]. RBP is expected to make TCP more conservative in sending
bursts of data after an idle period in hosts that do not revert to
slow start after an idle period. On the other hand, RBP makes TCP
more aggressive if the sender uses the slow start algorithm to start
the ACK clock after a long idle period.
3.6.4 Topology Considerations
RBP could be used to restart idle TCP connections for all topologies
in Section 2. Use at the beginning of new connections would be
restricted to topologies where available bandwidth can be estimated
out-of-band.
3.6.5 Possible Interaction and Relationships with Other Research
Pacing segments may benefit from sharing state amongst various flows
between two hosts, due to the time required to determine the needed
information. Additionally, pacing segments, rather than sending
back-to-back segments, may make estimating the available bandwidth
(as outlined in section 3.2.4) more difficult.
3.7 TCP Header Compression
The TCP and IP header information needed to reliably deliver packets
to a remote site across the Internet can add significant overhead,
especially for interactive applications. Telnet packets, for
example, typically carry only a few bytes of data per packet, and
standard IPv4/TCP headers add at least 40 bytes to this; IPv6/TCP
headers add at least 60 bytes. Much of this information remains
relatively constant over the course of a session and so can be
replaced by a short session identifier.
3.7.1 Mitigation Description
Many fields in the TCP and IP headers either remain constant during
the course of a session, change very infrequently, or can be inferred
from other sources. For example, the source and destination
addresses, as well as the IP version, protocol, and port fields
generally do not change during a session. Packet length can be
deduced from the length field of the underlying link layer protocol
provided that the link layer packet is not padded. Packet sequence
numbers in a forward data stream generally change with every packet,
but increase in a predictable manner.
The TCP/IP header compression methods described in
[DNP99,DENP97,Jac90] reduce the overhead of TCP sessions by replacing
the data in the TCP and IP headers that remains constant, changes
slowly, or changes in a predictable manner with a short "connection
number". Using this method, the sender first sends a full TCP/IP
header, including in it a connection number that the sender will use
to reference the connection. The receiver stores the full header and
uses it as a template, filling in some fields from the limited
information contained in later, compressed headers. This compression
can reduce the size of an IPv4/TCP headers from 40 to as few as 3 to
5 bytes (3 bytes for some common cases, 5 bytes in general).
Compression and decompression generally happen below the IP layer, at
the end-points of a given physical link (such as at two routers
connected by a serial line). The hosts on either side of the
physical link must maintain some state about the TCP connections that
are using the link.
The decompresser must pass complete, uncompressed packets to the IP
layer. Thus header compression is transparent to routing, for
example, since an incoming packet with compressed headers is expanded
before being passed to the IP layer.
A variety of methods can be used by the compressor/decompressor to
negotiate the use of header compression. For example, the PPP serial
line protocol allows for an option exchange, during which time the
compressor/decompressor agree on whether or not to use header
compression. For older SLIP implementations, [Jac90] describes a
mechanism that uses the first bit in the IP packet as a flag.
The reduction in overhead is especially useful when the link is
bandwidth-limited such as terrestrial wireless and mobile satellite
links, where the overhead associated with transmitting the header
bits is nontrivial. Header compression has the added advantage that
for the case of uniformly distributed bit errors, compressing TCP/IP
headers can provide a better quality of service by decreasing the
packet error probability. The shorter, compressed packets are less
likely to be corrupted, and the reduction in errors increases the
connection's throughput.
Extra space is saved by encoding changes in fields that change
relatively slowly by sending only their difference from their values
in the previous packet instead of their absolute values. In order to
decode headers compressed this way, the receiver keeps a copy of each
full, reconstructed TCP header after it is decoded, and applies the
delta values from the next decoded compressed header to the
reconstructed full header template.
A disadvantage to using this delta encoding scheme where values are
encoded as deltas from their values in the previous packet is that if
a single compressed packet is lost, subsequent packets with
compressed headers can become garbled if they contain fields which
depend on the lost packet. Consider a forward data stream of packets
with compressed headers and increasing sequence numbers. If packet N
is lost, the full header of packet N+1 will be reconstructed at the
receiver using packet N-1's full header as a template. Thus the
sequence number, which should have been calculated from packet N's
header, will be wrong, the checksum will fail, and the packet will be
discarded. When the sending TCP times out and retransmits a packet
with a full header is forwarded to re-synchronize the decompresser.
It is important to note that the compressor does not maintain any
timers, nor does the decompresser know when an error occurred (only
the receiving TCP knows this, when the TCP checksum fails). A single
bit error will cause the decompresser to lose sync, and subsequent
packets with compressed headers will be dropped by the receiving TCP,
since they will all fail the TCP checksum. When this happens, no
duplicate acknowledgments will be generated, and the decompresser can
only re-synchronize when it receives a packet with an uncompressed
header. This means that when header compression is being used, both
fast retransmit and selective acknowledgments will not be able
correct packets lost on a compressed link. The "twice" algorithm,
described below, may be a partial solution to this problem.
[DNP99] and [DENP97] describe TCP/IPv4 and TCP/IPv6 compression
algorithms including compressing the various IPv6 extension headers
as well as methods for compressing non-TCP streams. [DENP97] also
augments TCP header compression by introducing the "twice" algorithm.
If a particular packet fails to decompress properly, the twice
algorithm modifies its assumptions about the inferred fields in the
compressed header, assuming that a packet identical to the current
one was dropped between the last correctly decoded packet and the
current one. Twice then tries to decompress the received packet
under the new assumptions and, if the checksum passes, the packet is
passed to IP and the decompresser state has been re-synchronized.
This procedure can be extended to three or more decoding attempts.
Additional robustness can be achieved by caching full copies of
packets which don't decompress properly in the hopes that later
arrivals will fix the problem. Finally, the performance improvement
if the decompresser can explicitly request a full header is
discussed. Simulation results show that twice, in conjunction with
the full header request mechanism, can improve throughput over
uncompressed streams.
3.7.2 Research
[Jac90] outlines a simple header compression scheme for TCP/IP.
In [DENP97] the authors present the results of simulations showing
that header compression is advantageous for both low and medium
bandwidth links. Simulations show that the twice algorithm, combined
with an explicit header request mechanism, improved throughput by
10-15% over uncompressed sessions across a wide range of bit error
rates.
Much of this improvement may have been due to the twice algorithm
quickly re-synchronizing the decompresser when a packet is lost.
This is because the twice algorithm, applied one or two times when
the decompresser becomes unsynchronized, will re-sync the
decompresser in between 83% and 99% of the cases examined. This
means that packets received correctly after twice has resynchronized
the decompresser will cause duplicate acknowledgments. This re-
enables the use of both fast retransmit and SACK in conjunction with
header compression.
3.7.3 Implementation Issues
Implementing TCP/IP header compression requires changes at both the
sending (compressor) and receiving (decompresser) ends of each link
that uses compression. The twice algorithm requires very little
extra machinery over and above header compression, while the explicit
header request mechanism of [DENP97] requires more extensive
modifications to the sending and receiving ends of each link that
employs header compression. Header compression does not violate
TCP's congestion control mechanisms and therefore can be safely
implemented in shared networks.
3.7.4 Topology Considerations
TCP/IP header compression is applicable to all of the environments
discussed in section 2, but will provide relatively more improvement
in situations where packet sizes are small (i.e., overhead is large)
and there is medium to low bandwidth and/or higher BER. When TCP's
congestion window size is large, implementing the explicit header
request mechanism, the twice algorithm, and caching packets which
fail to decompress properly becomes more critical.
3.7.5 Possible Interaction and Relationships with Other Research
As discussed above, losing synchronization between a sender and
receiver can cause many packet drops. The frequency of losing
synchronization and the effectiveness of the twice algorithm may
point to using a SACK-based loss recovery algorithm to reduce the
impact of multiple lost segments. However, even very robust SACK-
based algorithms may not work well if too many segments are lost.
3.8 Sharing TCP State Among Similar Connections
3.8.1 Mitigation Description
Persistent TCP state information can be used to overcome limitations
in the configuration of the initial state, and to automatically tune
TCP to environments using satellite links and to coordinate multiple
TCP connections sharing a satellite link.
TCP includes a variety of parameters, many of which are set to
initial values which can severely affect the performance of TCP
connections traversing satellite links, even though most TCP
parameters are adjusted later after the connection is established.
These parameters include initial size of cwnd and initial MSS size.
Various suggestions have been made to change these initial
conditions, to more effectively support satellite links. However, it
is difficult to select any single set of parameters which is
effective for all environments.
An alternative to attempting to select these parameters a-priori is
sharing state across TCP connections and using this state when
initializing a new connection. For example, if all connections to a
subnet result in extended congestion windows of 1 megabyte, it is
probably more efficient to start new connections with this value,
than to rediscover it by requiring the cwnd to increase using slow
start over a period of dozens of round-trip times.
3.8.2 Research
Sharing state among connections brings up a number of questions such
as what information to share, with whom to share, how to share it,
and how to age shared information. First, what information is to be
shared must be determined. Some information may be appropriate to
share among TCP connections, while some information sharing may be
inappropriate or not useful. Next, we need to determine with whom to
share information. Sharing may be appropriate for TCP connections
sharing a common path to a given host. Information may be shared
among connections within a host, or even among connections between
different hosts, such as hosts on the same LAN. However, sharing
information between connections not traversing the same network may
not be appropriate. Given the state to share and the parties that
share it, a mechanism for the sharing is required. Simple state,
like MSS and RTT, is easy to share, but congestion window information
can be shared a variety of ways. The sharing mechanism determines
priorities among the sharing connections, and a variety of fairness
criteria need to be considered. Also, the mechanisms by which
information is aged require further study. See RFC2140 for a
discussion of the security issues in both sharing state within a
single host and sharing state among hosts on a subnet. Finally, the
security concerns associated with sharing a piece of information need
to be carefully considered before introducing such a mechanism. Many
of these open research questions must be answered before state
sharing can be widely deployed.
The opportunity for such sharing, both among a sequence of
connections, as well as among concurrent connections, is described in
more detail in [Tou97]. The state management itself is largely an
implementation issue, however what information should be shared and
the specific ways in which the information should be shared is an
open question.
Sharing parts of the TCB state was originally documented in T/TCP
[Bra92], and is used there to aggregate RTT values across connection
instances, to provide meaningful average RTTs, even though most
connections are expected to persist for only one RTT. T/TCP also
shares a connection identifier, a sequence number separate from the
window number and address/port pairs by which TCP connections are
typically distinguished. As a result of this shared state, T/TCP
allows a receiver to pass data in the SYN segment to the receiving
application, prior to the completion of the three-way handshake,
without compromising the integrity of the connection. In effect, this
shared state caches a partial handshake from the previous connection,
which is a variant of the more general issue of TCB sharing.
Sharing state among connections (including transfers using non-TCP
protocols) is further investigated in [BRS99].
3.8.3 Implementation Issues
Sharing TCP state across connections requires changes to the sender's
TCP stack, and possibly the receiver's TCP stack (as in the case of
T/TCP, for example). Sharing TCP state may make a particular TCP
connection more aggressive. However, the aggregate traffic should be
more conservative than a group of independent TCP connections.
Therefore, sharing TCP state should be safe for use in shared
networks. Note that state sharing does not present any new security
problems within multiuser hosts. In such a situation, users can
steal network resources from one another with or without state
sharing.
3.8.4 Topology Considerations
It is expected that sharing state across TCP connections may be
useful in all network environments presented in section 2.
3.8.5 Possible Interaction and Relationships with Other Research
The state sharing outlined above is very similar to the Congestion
Manager proposal [BRS99] that attempts to share congestion control
information among both TCP and UDP flows between a pair of hosts.
3.9 ACK Congestion Control
In highly asymmetric networks, a low-speed return link can restrict
the performance of the data flow on a high-speed forward link by
limiting the flow of acknowledgments returned to the data sender.
For example, if the data sender uses 1500 byte segments, and the
receiver generates 40 byte acknowledgments (IPv4, TCP without
options), the reverse link will congest with ACKs for asymmetries of
more than 75:1 if delayed ACKs are used, and 37:1 if every segment is
acknowledged. For a 1.5 Mb/second data link, ACK congestion will
occur for reverse link speeds below 20 kilobits/sec. These levels of
asymmetry will readily occur if the reverse link is shared among
multiple satellite receivers, as is common in many VSAT satellite
networks. If a terrestrial modem link is used as a reverse link, ACK
congestion is also likely, especially as the speed of the forward
link is increased. Current congestion control mechanisms are aimed
at controlling the flow of data segments, but do not affect the flow
of ACKs.
In [KVR98] the authors point out that the flow of acknowledgments can
be restricted on the low-speed link not only by the bandwidth of the
link, but also by the queue length of the router. The router may
limit its queue length by counting packets, not bytes, and therefore
begin discarding ACKs even if there is enough bandwidth to forward
them.
3.9.1 Mitigation Description
ACK Congestion Control extends the concept of flow control for data
segments to acknowledgment segments. In the method described in
[BPK97], any intermediate router can mark an acknowledgment with an
Explicit Congestion Notification (ECN) bit once the queue occupancy
in the router exceeds a given threshold. The data sender (which
receives the acknowledgment) must "echo" the ECN bit back to the data
receiver (see section 3.3.3 for a more detailed discussion of ECN).
The proposed algorithm for marking ACK segments with an ECN bit is
Random Early Detection (RED) [FJ93]. In response to the receipt of
ECN marked data segments, the receiver will dynamically reduce the
rate of acknowledgments using a multiplicative backoff. Once
segments without ECN are received, the data receiver speeds up
acknowledgments using a linear increase, up to a rate of either 1 (no
delayed ACKs) or 2 (normal delayed ACKs) data segments per ACK. The
authors suggest that an ACK be generated at least once per window,
and ideally a few times per window.
As in the RED congestion control mechanism for data flow, the
bottleneck gateway can randomly discard acknowledgments, rather than
marking them with an ECN bit, once the queue fills beyond a given
threshold.
3.9.2 Research
[BPK97] analyze the effect of ACK Congestion Control (ACC) on the
performance of an asymmetric network. They note that the use of ACC,
and indeed the use of any scheme which reduces the frequency of
acknowledgments, has potential unwanted side effects. Since each ACK
will acknowledge more than the usual one or two data segments, the
likelihood of segment bursts from the data sender is increased. In
addition, congestion window growth may be impeded if the receiver
grows the window by counting received ACKs, as mandated by
[Ste97,APS99]. The authors therefore combine ACC with a series of
modifications to the data sender, referred to as TCP Sender
Adaptation (SA). SA combines a limit on the number of segments sent
in a burst, regardless of window size. In addition, byte counting
(as opposed to ACK counting) is employed for window growth. Note
that byte counting has been studied elsewhere and can introduce
side-effects, as well [All98].
The results presented in [BPK97] indicate that using ACC and SA will
reduce the bursts produced by ACK losses in unmodified (Reno) TCP.
In cases where these bursts would lead to data loss at an
intermediate router, the ACC and SA modification significantly
improve the throughput for a single data transfer. The results
further suggest that the use of ACC and SA significantly improve
fairness between two simultaneous transfers.
ACC is further reported to prevent the increase in round trip time
(RTT) that occurs when an unmodified TCP fills the reverse router
queue with acknowledgments.
In networks where the forward direction is expected to suffer losses
in one of the gateways, due to queue limitations, the authors report
at best a very slight improvement in performance for ACC and SA,
compared to unmodified Reno TCP.
3.9.3 Implementation Issues
Both ACC and SA require modification of the sending and receiving
hosts, as well as the bottleneck gateway. The current research
suggests that implementing ACC without the SA modifications results
in a data sender which generates potentially disruptive segment
bursts. It should be noted that ACC does require host modifications
if it is implemented in the way proposed in [BPK97]. The authors
note that ACC can be implemented by discarding ACKs (which requires
only a gateway modification, but no changes in the hosts), as opposed
to marking them with ECN. Such an implementation may, however,
produce bursty data senders if it is not combined with a burst
mitigation technique. ACC requires changes to the standard ACKing
behavior of a receiving TCP and therefore is not recommended for use
in shared networks.
3.9.4 Topology Considerations
Neither ACC nor SA require the storage of state in the gateway.
These schemes should therefore be applicable for all topologies,
provided that the hosts using the satellite or hybrid network can be
modified. However, these changes are expected to be especially
beneficial to networks containing asymmetric satellite links.
3.9.5 Possible Interaction and Relationships with Other Research
Note that ECN is a pre-condition for using ACK congestion control.
Additionally, the ACK Filtering algorithm discussed in the next
section attempts to solve the same problem as ACC. Choosing between
the two algorithms (or another mechanism) is currently an open
research question.
3.10 ACK Filtering
ACK Filtering (AF) is designed to address the same ACK congestion
effects described in 3.9. Contrary to ACC, however, AF is designed
to operate without host modifications.
3.10.1 Mitigation Description
AF takes advantage of the cumulative acknowledgment structure of TCP.
The bottleneck router in the reverse direction (the low speed link)
must be modified to implement AF. Upon receipt of a segment which
represents a TCP acknowledgment, the router scans the queue for
redundant ACKs for the same connection, i.e. ACKs which acknowledge
portions of the window which are included in the most recent ACK.
All of these "earlier" ACKs are removed from the queue and discarded.
The router does not store state information, but does need to
implement the additional processing required to find and remove
segments from the queue upon receipt of an ACK.
3.10.2 Research
[BPK97] analyzes the effects of AF. As is the case in ACC, the use
of ACK filtering alone would produce significant sender bursts, since
the ACKs will be acknowledging more previously-unacknowledged data.
The SA modifications described in 3.9.2 could be used to prevent
those bursts, at the cost of requiring host modifications. To
prevent the need for modifications in the TCP stack, AF is more
likely to be paired with the ACK Reconstruction (AR) technique, which
can be implemented at the router where segments exit the slow reverse
link.
AR inspects ACKs exiting the link, and if it detects large "gaps" in
the ACK sequence, it generates additional ACKs to reconstruct an
acknowledgment flow which more closely resembles what the data sender
would have seen had ACK Filtering not been introduced. AR requires
two parameters; one parameter is the desired ACK frequency, while the
second controls the spacing, in time, between the release of
consecutive reconstructed ACKs.
In [BPK97], the authors show the combination of AF and AR to increase
throughput, in the networks studied, over both unmodified TCP and the
ACC/SA modifications. Their results also strongly suggest that the
use of AF alone, in networks where congestion losses are expected,
decreases performance (even below the level of unmodified TCP Reno)
due to sender bursting.
AF delays acknowledgments from arriving at the receiver by dropping
earlier ACKs in favor of later ACKs. This process can cause a slight
hiccup in the transmission of new data by the TCP sender.
3.10.3 Implementation Issues
Both ACK Filtering and ACK Reconstruction require only router
modification. However, the implementation of AR requires some
storage of state information in the exit router. While AF does not
require storage of state information, its use without AR (or SA)
could produce undesired side effects. Furthermore, more research is
required regarding appropriate ranges for the parameters needed in
AR.
3.10.4 Topology Considerations
AF and AR appear applicable to all topologies, assuming that the
storage of state information in AR does not prove to be prohibitive
for routers which handle large numbers of flows. The fact that TCP
stack modifications are not required for AF/AR makes this approach
attractive for hybrid networks and networks with diverse types of
hosts. These modifications, however, are expected to be most
beneficial in asymmetric network paths.
On the other hand, the implementation of AF/AR requires the routers
to examine the TCP header, which prohibits their use in secure
networks where IPSEC is deployed. In such networks, AF/AR can be
effective only inside the security perimeter of a private, or virtual
private network, or in private networks where the satellite link is
protected only by link-layer encryption (as opposed to IPSEC). ACK
Filtering is safe to use in shared networks (from a congestion
control point-of-view), as the number of ACKs can only be reduced,
which makes TCP less aggressive. However, note that while TCP is
less aggressive, the delays that AF induces (outlined above) can lead
to larger bursts than would otherwise occur.
3.10.5 Possible Interaction and Relationships with Other Research
ACK Filtering attempts to solve the same problem as ACK Congestion
Control (as outlined in section 3.9). Which of the two algorithms is
more appropriate is currently an open research question.
4 Conclusions
This document outlines TCP items that may be able to mitigate the
performance problems associated with using TCP in networks containing
satellite links. These mitigations are not IETF standards track
mechanisms and require more study before being recommended by the
IETF. The research community is encouraged to examine the above
mitigations in an effort to determine which are safe for use in
shared networks such as the Internet.
5 Security Considerations
Several of the above sections noted specific security concerns which
a given mitigation aggravates.
Additionally, any form of wireless communication link is more
susceptible to eavesdropping security attacks than standard wire-
based links due to the relative ease with which an attacker can watch
the network and the difficultly in finding attackers monitoring the
network.
6 Acknowledgments
Our thanks to Aaron Falk and Sally Floyd, who provided very helpful
comments on drafts of this document.
7 References
[AFP98] Allman, M., Floyd, S. and C. Partridge, "Increasing TCP's
Initial Window", RFC2414, September 1998.
[AGS99] Allman, M., Glover, D. and L. Sanchez, "Enhancing TCP Over
Satellite Channels using Standard Mechanisms", BCP 28, RFC
2488, January 1999.
[AHKO97] Mark Allman, Chris Hayes, Hans Kruse, Shawn Ostermann. TCP
Performance Over Satellite Links. In Proceedings of the
5th International Conference on Telecommunication Systems,
March 1997.
[AHO98] Mark Allman, Chris Hayes, Shawn Ostermann. An Evaluation
of TCP with Larger Initial Windows. Computer Communication
Review, 28(3), July 1998.
[AKO96] Mark Allman, Hans Kruse, Shawn Ostermann. An Application-
Level Solution to TCP's Satellite Inefficiencies. In
Proceedings of the First International Workshop on
Satellite-based Information Services (WOSBIS), November
1996.
[All97a] Mark Allman. Improving TCP Performance Over Satellite
Channels. Master's thesis, Ohio University, June 1997.
[All97b] Mark Allman. Fixing Two BSD TCP Bugs. Technical Report
CR-204151, NASA Lewis Research Center, October 1997.
[All98] Mark Allman. On the Generation and Use of TCP
Acknowledgments. ACM Computer Communication Review, 28(5),
October 1998.
[AOK95] Mark Allman, Shawn Ostermann, Hans Kruse. Data Transfer
Efficiency Over Satellite Circuits Using a Multi-Socket
Extension to the File Transfer Protocol (FTP). In
Proceedings of the ACTS Results Conference, NASA Lewis
Research Center, September 1995.
[AP99] Mark Allman, Vern Paxson. On Estimating End-to-End Network
Path Properties. ACM SIGCOMM, September 1999.
[APS99] Allman, M., Paxson, V. and W. Richard Stevens, "TCP
Congestion Control", RFC2581, April 1999.
[BCC+98] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering,
S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G.,
Partridge, C., Peterson, L., Ramakrishnan, K., Shenker, S.,
Wroclawski, J. and L. Zhang, "Recommendations on Queue
Management and Congestion Avoidance in the Internet", RFC
2309, April 1998.
[BKVP97] B. Bakshi and P. Krishna and N. Vaidya and D. Pradham,
"Improving Performance of TCP over Wireless Networks", 17th
International Conference on Distributed Computing Systems
(ICDCS), May 1997.
[BPK97] Hari Balakrishnan, Venkata N. Padmanabhan, and Randy H.
Katz. The Effects of Asymmetry on TCP Performance. In
Proceedings of the ACM/IEEE Mobicom, Budapest, Hungary,
ACM. September, 1997.
[BPK98] Hari Balakrishnan, Venkata Padmanabhan, Randy H. Katz. The
Effects of Asymmetry on TCP Performance. ACM Mobile
Networks and Applications (MONET), 1998 (to appear).
[BPSK96] H. Balakrishnan and V. Padmanabhan and S. Sechan and R.
Katz, "A Comparison of Mechanisms for Improving TCP
Performance over Wireless Links", ACM SIGCOMM, August 1996.
[Bra89] Braden, R., "Requirements for Internet Hosts --
Communication Layers", STD 3, RFC1122, October 1989.
[Bra92] Braden, R., "Transaction TCP -- Concepts", RFC1379,
September 1992.
[Bra94] Braden, R., "T/TCP -- TCP Extensions for Transactions:
Functional Specification", RFC1644, July 1994.
[BRS99] Hari Balakrishnan, Hariharan Rahul, and Srinivasan Seshan.
An Integrated Congestion Management Architecture for
Internet Hosts. ACM SIGCOMM, September 1999.
[ddKI99] M. deVivo, G.O. deVivo, R. Koeneke, G. Isern. Internet
Vulnerabilities Related to TCP/IP and T/TCP. Computer
Communication Review, 29(1), January 1999.
[DENP97] Mikael Degermark, Mathias Engan, Bjorn Nordgren, Stephen
Pink. Low-Loss TCP/IP Header Compression for Wireless
Networks. ACM/Baltzer Journal on Wireless Networks, vol.3,
no.5, p. 375-87.
[DMT96] R. C. Durst and G. J. Miller and E. J. Travis, "TCP
Extensions for Space Communications", Mobicom 96, ACM, USA,
1996.
[DNP99] Degermark, M., Nordgren, B. and S. Pink, "IP Header
Compression", RFC2507, February 1999.
[FF96] Kevin Fall, Sally Floyd. Simulation-based Comparisons of
Tahoe, Reno, and SACK TCP. Computer Communication Review,
V. 26 N. 3, July 1996, pp. 5-21.
[FF99] Sally Floyd, Kevin Fall. Promoting the Use of End-to-End
Congestion Control in the Internet, IEEE/ACM Transactions
on Networking, August 1999.
[FH99] Floyd, S. and T. Henderson, "The NewReno Modification to
TCP's Fast Recovery Algorithm", RFC2582, April 1999.
[FJ93] Sally Floyd and Van Jacobson. Random Early Detection
Gateways for Congestion Avoidance, IEEE/ACM Transactions on
Networking, V. 1 N. 4, August 1993.
[Flo91] Sally Floyd. Connections with Multiple Congested Gateways
in Packet-Switched Networks, Part 1: One-way Traffic. ACM
Computer Communications Review, V. 21, N. 5, October 1991.
[Flo94] Sally Floyd. TCP and Explicit Congestion Notification, ACM
Computer Communication Review, V. 24 N. 5, October 1994.
[Flo99] Sally Floyd. "Re: TCP and out-of-order delivery", email to
end2end-interest mailing list, February, 1999.
[Hah94] Jonathan Hahn. MFTP: Recent Enhancements and Performance
Measurements. Technical Report RND-94-006, NASA Ames
Research Center, June 1994.
[Hay97] Chris Hayes. Analyzing the Performance of New TCP
Extensions Over Satellite Links. Master's Thesis, Ohio
University, August 1997.
[HK98] Tom Henderson, Randy Katz. On Improving the Fairness of
TCP Congestion Avoidance. Proceedings of IEEE Globecom `98
Conference, 1998.
[HK99] Tim Henderson, Randy Katz. Transport Protocols for
Internet-Compatible Satellite Networks, IEEE Journal on
Selected Areas of Communications, February, 1999.
[Hoe95] J. Hoe, Startup Dynamics of TCP's Congestion Control and
Avoidance Schemes. Master's Thesis, MIT, 1995.
[Hoe96] Janey Hoe. Improving the Startup Behavior of a Congestion
Control Scheme for TCP. In ACM SIGCOMM, August 1996.
[IL92] David Iannucci and John Lakashman. MFTP: Virtual TCP
Window Scaling Using Multiple Connections. Technical
Report RND-92-002, NASA Ames Research Center, January 1992.
[Jac88] Van Jacobson. Congestion Avoidance and Control. In
Proceedings of the SIGCOMM '88, ACM. August, 1988.
[Jac90] Jacobson, V., "Compressing TCP/IP Headers", RFC1144,
February 1990.
[JBB92] Jacobson, V., Braden, R. and D. Borman, "TCP Extensions for
High Performance", RFC1323, May 1992.
[JK92] Van Jacobson and Mike Karels. Congestion Avoidance and
Control. Originally appearing in the proceedings of
SIGCOMM '88 by Jacobson only, this revised version includes
an additional appendix. The revised version is available
at ftp://ftp.ee.lbl.gov/papers/congavoid.ps.Z. 1992.
[Joh95] Stacy Johnson. Increasing TCP Throughput by Using an
Extended Acknowledgment Interval. Master's Thesis, Ohio
University, June 1995.
[KAGT98] Hans Kruse, Mark Allman, Jim Griner, Diepchi Tran. HTTP
Page Transfer Rates Over Geo-Stationary Satellite Links.
March 1998. Proceedings of the Sixth International
Conference on Telecommunication Systems.
[Kes91] Srinivasan Keshav. A Control Theoretic Approach to Flow
Control. In ACM SIGCOMM, September 1991.
[KM97] S. Keshav, S. Morgan. SMART Retransmission: Performance
with Overload and Random Losses. Proceeding of Infocom.
1997.
[KVR98] Lampros Kalampoukas, Anujan Varma, and K. K.Ramakrishnan.
Improving TCP Throughput Over Two-Way Asymmetric Links:
Analysis and Solutions. Measurement and Modeling of
Computer Systems, 1998, Pages 78-89.
[MM96a] M. Mathis, J. Mahdavi, "Forward Acknowledgment: Refining
TCP Congestion Control," Proceedings of SIGCOMM'96, August,
1996, Stanford, CA. Available from
http://www.psc.edu/networking/papers/papers.html
[MM96b] M. Mathis, J. Mahdavi, "TCP Rate-Halving with Bounding
Parameters" Available from
http://www.psc.edu/networking/papers/FACKnotes/current.
[MMFR96] Mathis, M., Mahdavi, J., Floyd, S. and A. Romanow, "TCP
Selective Acknowledgment Options", RFC2018, October 1996.
[MSMO97] M. Mathis, J. Semke, J. Mahdavi, T. Ott, "The Macroscopic
Behavior of the TCP Congestion Avoidance
Algorithm",Computer Communication Review, volume 27,
number3, July 1997. Available from
http://www.psc.edu/networking/papers/papers.html
[MV98] Miten N. Mehta and Nitin H. Vaidya. Delayed Duplicate-
Acknowledgments: A Proposal to Improve Performance of TCP
on Wireless Links. Technical Report 98-006, Department of
Computer Science, Texas A&M University, February 1998.
[Nic97] Kathleen Nichols. Improving Network Simulation with
Feedback. Com21, Inc. Technical Report. Available from
http://www.com21.com/pages/papers/068.pdf.
[PADHV99] Paxson, V., Allman, M., Dawson, S., Heavens, I. and B.
Volz, "Known TCP Implementation Problems", RFC2525, March
1999.
[Pax97] Vern Paxson. Automated Packet Trace Analysis of TCP
Implementations. In Proceedings of ACM SIGCOMM, September
1997.
[PN98] Poduri, K. and K. Nichols, "Simulation Studies of Increased
Initial TCP Window Size", RFC2415, September 1998.
[Pos81] Postel, J., "Transmission Control Protocol", STD 7, RFC
793, September 1981.
[RF99] Ramakrishnan, K. and S. Floyd, "A Proposal to add Explicit
Congestion Notification (ECN) to IP", RFC2481, January
1999.
[SF98] Nihal K. G. Samaraweera and Godred Fairhurst,
"Reinforcement of TCP error Recovery for Wireless
Communication", Computer Communication Review, volume 28,
number 2, April 1998.
[SP98] Shepard, T. and C. Partridge, "When TCP Starts Up With Four
Packets Into Only Three Buffers", RFC2416, September 1998.
[Ste97] Stevens, W., "TCP Slow Start, Congestion Avoidance, Fast
Retransmit, and Fast Recovery Algorithms", RFC2001,
January 1997.
[Sut98] B. Suter, T. Lakshman, D. Stiliadis, and A. Choudhury.
Design Considerations for Supporting TCP with Per-flow
Queueing. Proceedings of IEEE Infocom `98 Conference,
1998.
[Tou97] Touch, J., "TCP Control Block Interdependence", RFC2140,
April 1997.
[VH97a] Vikram Visweswaraiah and John Heidemann. Improving Restart
of Idle TCP Connections. Technical Report 97-661,
University of Southern California, 1997.
[VH97b] Vikram Visweswaraiah and John Heidemann. Rate-based pacing