As per Relevance of the word congestion, we have this rfc below:
Network Working Group G.
Request for Comments: 2757 Sun Microsystems, Inc
Category: Informational S.
Nortel
M.
University of
V.
N.
Texas A&M
January 2000
Long Thin
Status of this
This memo provides information for the Internet community. It
not specify an Internet standard of any kind. Distribution of
memo is unlimited
Copyright
Copyright (C) The Internet Society (2000). All Rights Reserved
In view of the unpredictable and problematic nature of long
networks (for example, wireless WANs), arriving at an
transport is a daunting task. We have reviewed the
proposals along with future research items. Based on this overview
we also recommend mechanisms for implementation in long
networks
Our goal is to identify a TCP that works for all users,
users of long thin networks. We started from the
recommendations of the IETF TCP Over Satellite Links (tcpsat)
group with this end in mind
We recognize that not every tcpsat recommendation will be
for long thin networks as well, and work toward a set of
recommendations that are 'benign' in environments that do not
them
Montenegro, et al. Informational [Page 1]
RFC 2757 Long Thin Networks January 2000
Table of
1 Introduction ................................................. 3
1.1 Network Architecture .................................... 5
1.2 Assumptions about the Radio Link ........................ 6
2 Should it be IP or Not? ..................................... 7
2.1 Underlying Network Error Characteristics ................ 7
2.2 Non-IP Alternatives ..................................... 8
2.2.1 WAP ................................................ 8
2.2.2 Deploying Non-IP Alternatives ...................... 9
2.3 IP-based Considerations ................................. 9
2.3.1 Choosing the MTU [Stevens94, RFC1144] .............. 9
2.3.2 Path MTU Discovery [RFC1191] ....................... 10
2.3.3 Non-TCP Proposals .................................. 10
3 The Case for TCP ............................................. 11
4 Candidate Optimizations ...................................... 12
4.1 TCP: Current Mechanisms ................................. 12
4.1.1 Slow Start and Congestion Avoidance ................ 12
4.1.2 Fast Retransmit and Fast Recovery .................. 12
4.2 Connection Setup with T/TCP [RFC1397, RFC1644] .......... 14
4.3 Slow Start Proposals .................................... 14
4.3.1 Larger Initial Window .............................. 14
4.3.2 Growing the Window during Slow Start ............... 15
4.3.2.1 ACK Counting .................................. 15
4.3.2.2 ACK-every-segment ............................. 16
4.3.3 Terminating Slow Start ............................. 17
4.3.4 Generating ACKs during Slow Start .................. 17
4.4 ACK Spacing ............................................. 17
4.5 Delayed Duplicate Acknowlegements ....................... 18
4.6 Selective Acknowledgements [RFC2018] .................... 18
4.7 Detecting Corruption Loss ............................... 19
4.7.1 Without Explicit Notification ...................... 19
4.7.2 With Explicit Notifications ........................ 20
4.8 Active Queue Management ................................. 21
4.9 Scheduling Algorithms ................................... 21
4.10 Split TCP and Performance-Enhancing Proxies (PEPs) ..... 22
4.10.1 Split TCP Approaches .............................. 23
4.10.2 Application Level Proxies ......................... 26
4.10.3 Snoop and its Derivatives ......................... 27
4.10.4 PEPs to handle Periods of Disconnection ........... 29
4.11 Header Compression Alternatives ........................ 30
4.12 Payload Compression .................................... 31
4.13 TCP Control Block Interdependence [Touch97] ............ 32
5 Summary of Recommended Optimizations ......................... 33
6 Conclusion ................................................... 35
7 Acknowledgements ............................................. 35
8 Security Considerations ...................................... 35
Montenegro, et al. Informational [Page 2]
RFC 2757 Long Thin Networks January 2000
9 References ................................................... 36
Authors' Addresses ............................................. 44
Full Copyright Statement ....................................... 46
1
Optimized wireless networking is one of the major hurdles that
Computing must solve if it is to enable ubiquitous access
networking resources. However, current data networking protocols
been optimized primarily for wired networks. Wireless
have very different characteristics in terms of latency, jitter,
error rate as compared to wired networks. Accordingly,
protocols are ill-suited to this medium
Mobile Wireless networks can be grouped in W-LANs (for example
802.11 compliant networks) and W-WANs (for example, CDPD [CDPD],
Ricochet, CDMA [CDMA], PHS, DoCoMo, GSM [GSM] to name a few). W-
present the most serious challenge, given that the length of
wireless link (expressed as the delay*bandwidth product) is
4 to 5 times as long as that of its W-LAN counterparts. For example
for an 802.11 network, assuming the delay (round-trip time) is
3 ms. and the bandwidth is 1.5 Mbps, the delay*bandwidth product
4500 bits. For a W-WAN such as Ricochet, a typical round-trip
may be around 500 ms. (the best is about 230 ms.), and the
bandwidth is about 24 Kbps. This yields a delay*bandwidth
roughly equal to 1.5 KB. In the near future, 3rd Generation
services will offer 384Kbps and more. Assuming a 200 ms round-trip
the delay*bandwidth product in this case is 76.8 Kbits (9.6 KB).
value is larger than the default 8KB buffer space used by many
implementations. This means that, whereas for W-LANs the
buffer space is enough, future W-WANs will operate
(that is, they will not be able to fill the pipe) unless
override the default value. A 3rd Generation wireless
offering 2 Mbps with 200-millisecond latency requires a 50 KB buffer
Most importantly, latency across a link adversely
throughput. For example, [MSMO97] derives an upper bound on
throughput. Indeed, the resultant expression is inversely related
the round-trip time
The long latencies also push the limits (and commonly
them) for what is acceptable to users of interactive applications
As a quick glance to our list of references will reveal, there is
wealth of proposals that attempt to solve the wireless
problem. In this document, we survey the different
available or under investigation, and issue the
recommendations
Montenegro, et al. Informational [Page 3]
RFC 2757 Long Thin Networks January 2000
There is a large body of work on the subject of improving
performance over satellite links. The documents under development
the tcpsat working group of the IETF [AGS98, ADGGHOSSTT98] are
relevant. In both cases, it is essential to start by improving
characteristics of the medium by using forward error correction (FEC
at the link layer to reduce the BER (bit error rate) from values
high as 10-3 to 10-6 or better. This makes the BER manageable.
in this realm, retransmission schemes like ARQ (automatic
request) may be used to bring it down even further. Notice
sometimes it may be desirable to forego ARQ because of the
delay it implies. In particular, time sensitive traffic (video
audio) must be delivered within a certain time limit beyond which
data is obsolete. Exhaustive retransmissions in this case
succeed in wasting time in order to deliver data that will
discarded once it arrives at its destination. This indicates
desirability of augmenting the protocol stack implementation
devices such that the upper protocol layers can inform the link
MAC layer when to avoid such costly retransmission schemes
Networks that include satellite links are examples of "long
networks" (LFNs or "elephants"). They are "long" networks
their round-trip time is quite high (for example, 0.5 sec and
for geosynchronous satellites). Not all satellite links fall
the LFN regime. In particular, round-trip times in a low-
orbiting (LEO) satellite network may be as little as a
milliseconds (and never extend beyond 160 to 200 ms). W-WANs
the "L" with LFNs. However, satellite networks are also "fat" in
sense that they may have high bandwidth. Satellite networks may
have a delay*bandwidth product above 64 KBytes, in which case
pose additional problems to TCP [TCPHP]. W-WANs do not
exhibit this behavior. Accordingly, this document only deals
links that are "long thin pipes", and the networks that contain them
"long thin networks". We call these "LTNs".
This document does not give an overview of the API used to access
underlying transport. We believe this is an orthogonal issue,
though some of the proposals below have been put forth assuming
given interface. It is possible, for example, to support
traditional socket semantics without fully relying on TCP/
transport [MOWGLI].
Our focus is on the on-the-wire protocols. We try to include the
relevant ones and briefly (given that we provide the
needed for further study) mention their most salient points
Montenegro, et al. Informational [Page 4]
RFC 2757 Long Thin Networks January 2000
1.1 Network
One significant difference between LFNs and LTNs is that we
the W-WAN link is the last hop to the end user. This allows us
assume that a single intermediate node sees all packets
between the wireless mobile device and the rest of the Internet
This is only one of the topologies considered by the TCP
community
Given our focus on mobile wireless applications, we only consider
very specific architecture that includes
- a wireless mobile device, connected
- a wireless link (which may, in fact comprise several hops
the link layer),
- an intermediate node (sometimes referred to as a base station
connected
- a wireline link, which in turn interfaces
- the landline Internet and millions of legacy servers and
sites
Specifically, we are not as concerned with paths that include
wireless segments separated by a wired one. This may occur,
example, if one mobile device connects across its immediate
segment via an intermediate node to the Internet, and then via
second wireless segment to another mobile device. Quite often
mobile devices connect to a legacy server on the wired Internet
Typically, the endpoints of the wireless segment are the
node and the mobile device. However, the latter may be a
router to a mobile network. This is also important and
applications in, for example, disaster recovery
Our target architecture has implications which concern
deployability of candidate solutions. In particular, an
requirement is that we cannot alter the networking stack on
legacy servers. It would be preferable to only change the
stack at the intermediate node, although changing it at the
devices is certainly an option and perhaps a necessity
We envision mobile devices that can use the wireless medium
efficiently, but overcome some of its traditional constraints.
is, full mobility implies that the devices have the flexibility
agility to use whichever happens to be the best network
Montenegro, et al. Informational [Page 5]
RFC 2757 Long Thin Networks January 2000
available at any given point in time or space. Accordingly,
could switch from a wired office LAN and hand over their
connections to continue on, say, a wireless WAN. This type of
also requires Mobile IP [RFC2002].
1.2 Assumptions about the Radio
The system architecture described above assumes at most one
link (perhaps comprising more than one wireless hop). However,
is not enough to characterize a wireless link.
considerations are
- What are the error characteristics of the wireless medium?
link may present a higher BER than a wireline network due
burst errors and disconnections. The techniques below
do not address all the types of errors. Accordingly, a
solution should combine the best of all the proposals
Nevertheless, in this document we are more concerned with (
give preference to solving) the most typical case: (1)
BER due to random errors (which implies longer and
variable delays due to link-layer error corrections
retransmissions) rather than (2) an interruption in service
to a handoff or a disconnection. The latter are also
and we do include relevant proposals in this survey
- Is the wireless service datagram oriented, or is it a
circuit? Currently, switched virtual circuits are more common
but packet networks are starting to appear, for example
Metricom's Starmode [CB96], CDPD [CDPD] and General
Radio Service (GPRS) [GPRS],[BW97] in GSM
- What kind of reliability does the link provide?
services typically retransmit a packet (frame) until it
been acknowledged by the target. They may allow the user
turn off this behavior. For example, GSM allows RLP [RLP
(Radio Link Protocol) to be turned off. Metricom has
similar "lightweight" mode. In GSM RLP, a frame
retransmitted until the maximum number of
(protocol parameter) is reached. What happens when this
is reached is determined by the telecom operator: the
link connection is either disconnected or a link reset
enforced where the sequence numbers are resynchronized and
transmit and receive buffers are flushed resulting in
data. Some wireless services, like CDMA IS95-RLP [CDMA
Karn93], limit the latency on the wireless link
retransmitting a frame only a couple of times. This
the residual frame error rate significantly, but does
provide fully reliable link service
Montenegro, et al. Informational [Page 6]
RFC 2757 Long Thin Networks January 2000
- Does the mobile device transmit and receive at the same time
Doing so increases the cost of the electronics on the
device. Typically, this is not the case. We assume in
document that mobile devices do not transmit and
simultaneously
- Does the mobile device directly address more than one peer
the wireless link? Packets to each different peer may
spatially distinct wireless paths. Accordingly, the path
each peer may exhibit very different characteristics.
commonly, the mobile device addresses only one peer (
intermediate node) at any given point in time. When this
not the case, techniques such as Channel-State Dependent
Scheduling come into play (see the section "Packet Scheduling
below).
2 Should it be IP or Not
The first decision is whether to use IP as the underlying
protocol or not. In particular, some data protocols evolved
wireless telephony are not always -- though at times they may be --
layered on top of IP [MOWGLI, WAP]. These proposals are based on
concept of proxies that provide adaptation services between
wireless and wireline segments
This is a reasonable model for mobile devices that always
through the proxy. However, we expect many wireless mobile devices
utilize wireline networks whenever they are available. This
closely follows current laptop usage patterns: devices
utilize LANs, and only resort to dial-up access when "out of
office."
For these devices, an architecture that assumes IP is the
approach, because it will be required for communications that do
traverse the intermediate node (for example, upon reconnection to
W-LAN or a 10BaseT network at the office).
2.1 Underlying Network Error
Using IP as the underlying network protocol requires a certain (low
level of link robustness that is expected of wireless links
IP, and the protocols that are carried in IP packets, are
end-to-end by checksums that are relatively weak [Stevens94,
Paxson97] (and, in some cases, optional). For much of the Internet
these checksums are sufficient; in wireless environments, the
characteristics of the raw wireless link are much less robust
the rest of the end-to-end path. Hence for paths that
Montenegro, et al. Informational [Page 7]
RFC 2757 Long Thin Networks January 2000
wireless links, exclusively relying on end-to-end mechanisms
detect and correct transmission errors is undesirable. These
be complemented by local link-level mechanisms. Otherwise, damaged
packets are propagated through the network only to be discarded
the destination host. For example, intermediate routers are
to check the IP header checksum, but not the UDP or TCP checksums
Accordingly, when the payload of an IP packet is corrupted, this
not detected until the packet arrives at its ultimate destination
A better approach is to use link-layer mechanisms such as FEC
retransmissions, and so on in order to improve the characteristics
the wireless link and present a much more reliable service to IP
This approach has been taken by CDPD, Ricochet and CDMA
This approach is roughly analogous to the successful deployment
Point-to-Point Protocol (PPP), with robust framing and 16-
checksumming, on wireline networks as a replacement for the
Line Interface Protocol (SLIP), with only a single framing byte
no checksumming
[AGS98] recommends the use of FEC in satellite environments
Notice that the link-layer could adapt its frame size to
prevalent BER. It would perform its own fragmentation and
so that IP could still enjoy a large enough MTU size [LS98].
A common concern for using IP as a transport is the header
it implies. Typically, the underlying link-layer appears as
[RFC1661] to the IP layer above. This allows for header
schemes [IPHC, IPHC-RTP, IPHC-PPP] which greatly alleviate
problem
2.2 Non-IP
A number of non-IP alternatives aimed at wireless environments
been proposed. One representative proposal is discussed here
2.2.1
The Wireless Application Protocol (WAP) specifies an
framework and network protocols for wireless devices such as
telephones, pagers, and PDAs [WAP]. The architecture requires a
between the mobile device and the server. The WAP protocol stack
layered over a datagram transport service. Such a service
provided by most wireless networks; for example, IS-136,
SMS/USSD, and UDP in IP networks like CDPD and GSM GPRS. The core
Montenegro, et al. Informational [Page 8]
RFC 2757 Long Thin Networks January 2000
the WAP protocols is a binary HTTP/1.1 protocol with
features such as header caching between requests and a shared
between client and server
2.2.2 Deploying Non-IP
IP is such a fundamental element of the Internet that non-
alternatives face substantial obstacles to deployment, because
do not exploit the IP infrastructure. Any non-IP alternative that
used to provide gatewayed access to the Internet must map between
addresses and non-IP addresses, must terminate IP-level security at
gateway, and cannot use IP-oriented discovery protocols (Dynamic
Configuration Protocol, Domain Name Services, Lightweight
Access Protocol, Service Location Protocol, etc.) without
at a gateway
A further complexity occurs when a device supports both wireless
wireline operation. If the device uses IP for wireless operation
uninterrupted operation when the device is connected to a
network is possible (using Mobile IP). If a non-IP alternative
used, this switchover is more difficult to accomplish
Non-IP alternatives face the burden of proof that IP is so ill-
to a wireless environment that it is not a viable technology
2.3 IP-based
Given its worldwide deployment, IP is an obvious choice for
underlying network technology. Optimizations implemented at
level benefit traditional Internet application protocols as well
new ones layered on top of IP or UDP
2.3.1 Choosing the MTU [Stevens94, RFC1144]
In slow networks, the time required to transmit the largest
packet may be considerable. Interactive response time should
exceed the well-known human factors limit of 100 to 200 ms.
should be considered the maximum time budget to (1) send a packet
(2) obtain a response. In most networking stack implementations, (1)
is highly dependent on the maximum transmission unit (MTU). In
worst case, a small packet from an interactive application may
to wait for a large packet from a bulk transfer application
being sent. Hence, a good rule of thumb is to choose an MTU such
its transmission time is less than (or not much larger than) 200 ms
Montenegro, et al. Informational [Page 9]
RFC 2757 Long Thin Networks January 2000
Of course, compression and type-of-service queuing (
interactive data packets are given a higher priority) may
this problem. In particular, the latter may reduce the average
time to about half the MTU's transmission time
2.3.2 Path MTU Discovery [RFC1191]
Path MTU discovery benefits any protocol built on top of IP.
allows a sender to determine what the maximum end-to-end
unit is to a given destination. Without Path MTU discovery,
default IPv4 MTU size is 576. The benefits of using a larger MTU are
- Smaller ratio of header overhead to
- Allows TCP to grow its congestion window faster, since
increases in units of segments
Of course, for a given BER, a larger MTU has a correspondingly
probability of error within any given segment. The BER may be
using lower level techniques like FEC and link-layer retransmissions
The issue is that now delays may become a problem due to
additional retransmissions, and the fact that packet
time increases with a larger MTU
Recommendation: Path MTU discovery is recommended. [AGS98]
recommends its use in satellite environments
2.3.3 Non-TCP
Other proposals assume an underlying IP datagram service,
implement an optimized transport either directly on top of
[NETBLT] or on top of UDP [MNCP]. Not relying on TCP is a bold move
given the wealth of experience and research related to it. It
be argued that the Internet has not collapsed because its
protocol, TCP, is very careful in how it uses the network,
generally treats it as a black box assuming all packet losses are
to congestion and prudently backing off. This avoids
congestion
However, in the wireless medium, packet losses may also be due
corruption due to high BER, fading, and so on. Here, the
approach is to try harder, instead of backing off.
transport protocols are
- NETBLT [NETBLT, RFC1986, RFC1030]
- MNCP [MNCP
Montenegro, et al. Informational [Page 10]
RFC 2757 Long Thin Networks January 2000
- ESRO [RFC2188]
- RDP [RFC908, RFC1151]
- VMTP [VMTP
3 The Case for
This is one of the most hotly debated issues in the wireless arena
Here are some arguments against it
- It is generally recognized that TCP does not perform well
the presence of significant levels of non-congestion loss.
detractors argue that the wireless medium is one such case,
that it is hard enough to fix TCP. They argue that it is
to start from scratch
- TCP has too much header overhead
- By the time the mechanisms are in place to fix it, TCP is
heavy, and ill-suited for use by lightweight, portable devices
and here are some in support of TCP
- It is preferable to continue using the same protocol that
rest of the Internet uses for compatibility reasons.
extensions specific to the wireless link may be negotiated
- Legacy mechanisms may be reused (for example three-
handshake).
- Link-layer FEC and ARQ can reduce the BER such that any
TCP does see are, in fact, caused by congestion (or a
interruption of link connectivity). Modern W-WAN
do this (CDPD, US-TDMA, CDMA, GSM), thus improving
throughput
- Handoffs among different technologies are made possible
Mobile IP [RFC2002], but only if the same protocols,
TCP/IP, are used throughout
- Given TCP's wealth of research and experience,
protocols are relatively immature, and the full implications
their widespread deployment not clearly understood
Overall, we feel that the performance of TCP over long-thin
can be improved significantly. Mechanisms to do so are discussed
the next sections
Montenegro, et al. Informational [Page 11]
RFC 2757 Long Thin Networks January 2000
4 Candidate
There is a large volume of work on the subject of optimizing TCP
operation over wireless media. Even though satellite
generally fall in the LFN regime, our current LTN focus has much
benefit from it. For example, the work of the TCP-over-
working group of the IETF has been extremely helpful in
this section [AGS98, ADGGHOSSTT98].
4.1 TCP: Current
A TCP sender adapts its use of bandwidth based on feedback from
receiver. The high latency characteristic of LTNs implies that TCP'
adaptation is correspondingly slower than on networks with
delays. Similarly, delayed ACKs exacerbate the perceived latency
the link. Given that TCP grows its congestion window in units
segments, small MTUs may slow adaptation even further
4.1.1 Slow Start and Congestion
Slow Start and Congestion Avoidance [RFC2581] are essential
Internet's stability. However there are two reasons why the
medium adversely affects them
- Whenever TCP's retransmission timer expires, the sender
that the network is congested and invokes slow start. This
why it is important to minimize the losses caused
corruption, leaving only those caused by congestion (
expected by TCP).
- The sender increases its window based on the number of
received. Their rate of arrival, of course, is dependent on
RTT (round-trip-time) between sender and receiver,
implies long ramp-up times in high latency links like LTNs.
dependency lasts until the pipe is filled
- During slow start, the sender increases its window in units
segments. This is why it is important to use an
large MTU which, in turn, requires requires link layers
low loss
4.1.2 Fast Retransmit and Fast
When a TCP sender receives several duplicate ACKs, fast
[RFC2581] allows it to infer that a segment was lost. The
retransmits what it considers to be this lost segment without
for the full timeout, thus saving time
Montenegro, et al. Informational [Page 12]
RFC 2757 Long Thin Networks January 2000
After a fast retransmit, a sender invokes the fast recovery [RFC2581]
algorithm. Fast recovery allows the sender to transmit at half
previous rate (regulating the growth of its window based
congestion avoidance), rather than having to begin a slow start.
also saves time
In general, TCP can increase its window beyond the delay-
product. However, in LTN links the congestion window may
rather small, less than four segments, for long periods of time
to any of the following reasons
1. Typical "file size" to be transferred over a connection
relatively small (Web requests, Web document objects,
messages, files, etc.) In particular, users of LTNs are
very willing to carry out large transfers as the response
is so long
2. If the link has high BER, the congestion window tends to
3. When an LTN is combined with a highly congested
Internet path, congestion losses on the Internet have the
effect as 2.
4. Commonly, ISPs/operators configure only a small number
buffers (even as few as for 3 packets) per user in their dial
up
5. Often small socket buffers are recommended with LTNs in
to prevent the RTO from inflating and to diminish the amount
packets with competing traffic
A small window effectively prevents the sender from taking
of Fast Retransmits. Moreover, efficient recovery from
losses within a single window requires adoption of new
(NewReno [RFC2582]). In addition, on slow paths with no
reordering waiting for three duplicate ACKs to arrive
retransmission unnecessarily
Recommendation: Implement Fast Retransmit and Fast Recovery at
time. This is a widely-implemented optimization and is currently
Proposed Standard level. [AGS98] recommends implementation of
Retransmit/Fast Recovery in satellite environments.
[RFC2582] apparently does help a sender better handle partial
and multiple losses in a single window, but at this point is
recommended due to its experimental nature. Instead, SACK [RFC2018]
is the preferred mechanism
Montenegro, et al. Informational [Page 13]
RFC 2757 Long Thin Networks January 2000
4.2 Connection Setup with T/TCP [RFC1397, RFC1644]
TCP engages in a "three-way handshake" whenever a new connection
set up. Data transfer is only possible after this phase
completed successfully. T/TCP allows data to be exchanged
parallel with the connection set up, saving valuable time for
transactions on long-latency networks
Recommendation: T/TCP is not recommended, for these reasons
- It is an Experimental RFC
- It is not widely deployed, and it has to be deployed at both
of a connection
- Security concerns have been raised that T/TCP is more
to address-spoofing attacks than TCP itself
- At least some of the benefits of T/TCP (eliminating three-
handshake on subsequent query-response transactions, for instance
are also available with persistent connections on HTTP/1.1,
is more widely deployed
[ADGGHOSSTT98] does not have a recommendation on T/TCP in
environments
4.3 Slow Start
Because slow start dominates the network response seen by
users at the beginning of a TCP connection, a number of
have been made to modify or eliminate slow start in long
environments
Stability of the Internet is paramount, so these proposals
demonstrate that they will not adversely affect Internet
levels in significant ways
4.3.1 Larger Initial
Traditional slow start, with an initial window of one segment, is
time-consuming bandwidth adaptation procedure over LTNs. Studies
an initial window larger than one segment [RFC2414, AHO98]
in the TCP standard supporting a maximum value of 2 [RFC2581].
values are still experimental in nature
Montenegro, et al. Informational [Page 14]
RFC 2757 Long Thin Networks January 2000
In simulations with an increased initial window of three
[RFC2415], this proposal does not contribute significantly to
drop rates, and it has the added benefit of improving
response times when the peer device delays acknowledgements
slow start (see next proposal).
[RFC2416] addresses situations where the initial window exceeds
number of buffers available to TCP and indicates that this
is no different from the case where the congestion window
beyond the number of buffers available
[RFC2581] now allows an initial congestion window of two segments.
larger initial window, perhaps as many as four segments, might
allowed in the future in environments where this
improves performance (LFNs and LTNs).
Recommendation: Implement this on devices now. The research on
optimization indicates that 3 segments is a safe initial setting,
is centering on choosing between 2, 3, and 4. For now, use 2
(following RFC2581), which at least allows clients running query
response applications to get an initial ACK from unmodified
without waiting for a typical delayed ACK timeout of 200
milliseconds, and saves two round-trips. An initial window of 3
[RFC2415] looks promising and may be adopted in the future
further research and experience
4.3.2 Growing the Window during Slow
The sender increases its window based on the flow of ACKs coming
from the receiver. Particularly during slow start, this flow is
important. A couple of the proposals that have been studied are (1)
ACK counting and (2) ACK-every-segment
4.3.2.1 ACK
The main idea behind ACK counting is
- Make each ACK count to its fullest by growing the window
on the data being acknowledged (byte counting) instead of
number of ACKs (ACK counting). This has been shown to
bursts which lead to congestion. [Allman98] shows that
Byte Counting (LBC), in which the window growth is limited to 2
segments, does not lead to as much burstiness, and offers
performance gains
Recommendation: Unlimited byte counting is not recommended.
Jacobson cautions against byte counting [TCPSATMIN] because it
to burstiness, and recommends ACK spacing [ACKSPACING] instead
Montenegro, et al. Informational [Page 15]
RFC 2757 Long Thin Networks January 2000
ACK spacing requires ACKs to consistently pass through a single ACK
spacing router. This requirement works well for W-WAN
if the ACK-spacing router is also the intermediate node
Limited byte counting warrants further investigation before we
recommend this proposal, but it shows promise
4.3.2.2 ACK-every-
The main idea behind ACK-every-segment is
- Keep a constant stream of ACKs coming back by turning
delayed ACKs [RFC1122] during slow start. ACK-every-
must be limited to slow start, in order to avoid
asymmetric-bandwidth configurations. For instance, a
bandwidth link carrying acknowledgements back to the sender
hinders the growth of the congestion window, even if the
toward the client has a greater bandwidth [BPK99].
Even though simulations confirm its promise (it allows receivers
receive the second segment from unmodified senders without
for a typical delayed ACK timeout of 200 milliseconds), for
technique to be practical the receiver must acknowledge every
only when the sender is in slow start. Continuing to do so when
sender is in congestion avoidance may have adverse effects on
mobile device's battery consumption and on traffic in the network
This violates a SHOULD in [RFC2581]: delayed acknowledgements
be used by a TCP receiver
"Disabling Delayed ACKs During Slow Start" is
unimplementable, as the receiver has no way of knowing when
sender crosses ssthresh (the "slow start threshold") and begins
the congestion avoidance algorithm. If receivers
recommendations for increased initial windows, disabling delayed
during an increased initial window would open the TCP window
rapidly without doubling ACK traffic in general. However,
scheme might double ACK traffic if most connections remain in slow
start
Recommendation: ACK only the first segment on a new connection
no delay
Montenegro, et al. Informational [Page 16]
RFC 2757 Long Thin Networks January 2000
4.3.3 Terminating Slow
New mechanisms [ADGGHOSSTT98] are being proposed to improve TCP'
adaptive properties such that the available bandwidth is
utilized while reducing the possibility of congesting the network
This results in the closing of the congestion window to 1
(which precludes fast retransmit), and the subsequent slow
phase
Theoretically, an optimum value for slow-start threshold (ssthresh
allows connection bandwidth utilization to ramp up as aggressively
possible without "overshoot" (using so much bandwidth that
are lost and congestion avoidance procedures are invoked).
Recommendation: Estimating the slow start threshold is
recommended. Although this would be helpful if we knew how to do it
rough consensus on the tcp-impl and tcp-sat mailing lists is that
non-trivial operational networks there is no reliable method to
during TCP startup and estimate the bandwidth available
4.3.4 Generating ACKs during Slow
Mitigations that inject additional ACKs (whether "ACK-first-segment
or "ACK-every-segment-during-slow-start") beyond what today'
conformant TCPs inject are only applicable during the slow-
phases of a connection. After an initial exchange, the
usually completes slow-start, so TCPs only inject additional
when (1) the connection is closed, and a new connection is opened,
(2) the TCPs handle idle connection restart correctly by
slow start
Item (1) is typical when using HTTP/1.0, in which each request
response transaction requires a new connection.
connections in HTTP/1.1 help in maintaining a connection
congestion avoidance instead of constantly reverting to slow-start
Because of this, these optimizations which are only enabled
slow-start do not get as much of a chance to act. Item (2),
course, is independent of HTTP version
4.4 ACK
During slow start, the sender responds to the incoming ACK stream
transmitting N+1 segments for each ACK, where N is the number of
segments acknowledged by the incoming ACK. This results in
being sent at twice the speed at which it can be processed by
network. Accordingly, queues will form, and due to
buffering at the bottleneck router, packets may get dropped
the link's capacity is full
Montenegro, et al. Informational [Page 17]
RFC 2757 Long Thin Networks January 2000
Spacing out the ACKs effectively controls the rate at which
sender will transmit into the network, and may result in little or
queueing at the bottleneck router [ACKSPACING]. Furthermore,
spacing reduces the size of the bursts
Recommendation: No recommendation at this time. Continue
research in this area
4.5 Delayed Duplicate
As was mentioned above, link-layer retransmissions may decrease
BER enough that congestion accounts for most of packet losses; still
nothing can be done about interruptions due to handoffs,
beyond wireless coverage, etc. In this scenario, it is imperative
prevent interaction between link-layer retransmission and
retransmission as these layers duplicate each other's efforts.
such an environment it may make sense to delay TCP's efforts so as
give the link-layer a chance to recover. With this in mind,
Delayed Dupacks [MV97, Vaidya99] scheme selectively delays
acknowledgements at the receiver. It is preferable to allow a
mechanism to resolve a local problem, instead of invoking TCP's end
to-end mechanism and incurring the associated costs, both in terms
wasted bandwidth and in terms of its effect on TCP's window behavior
The Delayed Dupacks scheme can be used despite IP encryption
the intermediate node does not need to examine the TCP headers
Currently, it is not well understood how long the receiver
delay the duplicate acknowledgments. In particular, the impact
wireless medium access control (MAC) protocol on the choice of
parameter needs to be studied. The MAC protocol may affect
ability to choose the appropriate delay (either statically
dynamically). In general, significant variabilities in link-
retransmission times can have an adverse impact on the performance
the Delayed Dupacks scheme. Furthermore, as discussed later
section 4.10.3, Delayed Dupacks and some other schemes (such as
[SNOOP]) are only beneficial in certain types of network links
Recommendation: Delaying duplicate acknowledgements may be useful
specific network topologies, but a general recommendation
further research and experience
4.6 Selective Acknowledgements [RFC2018]
SACK may not be useful in many LTNs, according to Section 1.1
[TCPHP]. In particular, SACK is more useful in the LFN regime
especially if large windows are being used, because there is
Montenegro, et al. Informational [Page 18]
RFC 2757 Long Thin Networks January 2000
considerable probability of multiple segment losses per window.
the LTN regime, TCP windows are much smaller, and burst errors
be much longer in duration in order to damage multiple segments
Accordingly, the complexity of SACK may not be justifiable,
there is a high probability of burst errors and congestion on
wireless link. A desire for compatibility with TCP
for non-LTN environments may dictate LTN support for SACK anyway
[AGS98] recommends use of SACK with Large TCP Windows in
environments, and notes that this implies support for
(Protection Against Wrapped Sequence space) and RTTM (Round Trip
Measurement) as well
Berkeley's SNOOP protocol research [SNOOP] indicates that SACK
improve throughput for SNOOP when multiple segments are lost
window [BPSK96]. SACK allows SNOOP to recover from multi-
losses in one round-trip. In this case, the mobile device needs
implement some form of selective acknowledgements. If SACK is
used, TCP may enter congestion avoidance as the time needed
retransmit the lost segments may be greater than the
timer
Recommendation: Implement SACK now for compatibility with other
and improved performance with SNOOP
4.7 Detecting Corruption
4.7.1 Without Explicit
In the absence of explicit notification from the network,
researchers have suggested statistical methods for
avoidance [Jain89, WC91, VEGAS]. A natural extension of
heuristics would enable a sender to distinguish between losses
by congestion and other causes. The research results on
reliability of sender-based heuristics is unfavorable [BV97, BV98].
[BV98a] reports better results in constrained environments
packet inter-arrival times measured at the receiver, but highly
variable delay - of the type encountered in wireless
during intercell handoff - confounds these heuristics
Recommendation: No recommendation at this time - continue to
research results
Montenegro, et al. Informational [Page 19]
RFC 2757 Long Thin Networks January 2000
4.7.2 With Explicit
With explicit notification from the network it is possible
determine when a loss is due to congestion. Several proposals
these lines include
- Explicit Loss Notification (ELN) [BPSK96]
- Explicit Bad State Notification (EBSN) [BBKVP96]
- Explicit Loss Notification to the Receiver (ELNR), and
Delayed Dupack Activation Notification (EDDAN) (
to mobile receiver) [MV97]
- Explicit Congestion Notification (ECN) [ECN
Of these proposals, Explicit Congestion Notification (ECN)
closest to deployment on the Internet, and will provide some
for TCP connections on long thin networks (as well as for all
TCP connections).
Recommendation: No recommendation at this time. Schemes like ELNR
EDDAN [MV97], in which the only systems that need to be modified
the intermediate node and the mobile device, are slated for
pending further research. However, this solution has
limitations. Since the intermediate node must have access to the
headers, the IP payload must not be encrypted
ECN uses the TOS byte in the IP header to carry
information (ECN-capable and Congestion-encountered). This byte
not encrypted in IPSEC, so ECN can be used on TCP connections
are encrypted using IPSEC
Recommendation: Implement ECN. In spite of this, mechanisms
explicit corruption notification are still relevant and should
tracked
Note: ECN provides useful information to avoid deteriorating
a bad situation, but has some limitations for wireless applications
Absence of packets marked with ECN should not be interpreted by ECN
capable TCP connections as a green light for
retransmissions. On the contrary, during periods of extreme
congestion routers may drop packets marked with explicit
because their buffers are exhausted - exactly the wrong time for
host to begin retransmitting aggressively
Montenegro, et al. Informational [Page 20]
RFC 2757 Long Thin Networks January 2000
4.8 Active Queue
As has been pointed out above, TCP responds to congestion by
down the window and invoking slow start. Long-delay networks take
particularly long time to recover from this condition. Accordingly
it is imperative to avoid congestion in LTNs. To remedy this,
queue management techniques have been proposed as enhancements
routers throughout the Internet [RED]. The primary motivation
deployment of these mechanisms is to prevent "congestion collapse" (
severe degradation in service) by controlling the average queue
at the routers. As the average queue length grows, Random
Detection [RED] increases the possibility of dropping packets
The benefits are
- Reduce packet drops in routers. By dropping a few
before severe congestion sets in, RED avoids dropping bursts
packets. In other words, the objective is to drop m
early to prevent n drops later on, where m is less than n
- Provide lower delays. This follows from the smaller
sizes, and is particularly important for
applications, for which the inherent delays of wireless
already push the user experience to the limits of the non
acceptable
- Avoid lock-outs. Lack of resources in a router (and
resultant packet drops) may, in effect, obliterate
on certain connections. Because of active queue management,
is more probable for an incoming packet to find
buffer space at the router
Active Queue Management has two components: (1) routers
congestion before exhausting their resources, and (2) they
some form of congestion indication. Dropping packets via RED is
one example of the latter. Another way to indicate congestion is
use ECN [ECN] as discussed above under "Detecting Corruption Loss
With Explicit Notifications."
Recommendation: RED is currently being deployed in the Internet,
LTNs should follow suit. ECN deployment should complement RED's
4.9 Scheduling
Active queue management helps control the length of the queues
Additionally, a general solution requires replacing FIFO with
scheduling algorithms that improve
Montenegro, et al. Informational [Page 21]
RFC 2757 Long Thin Networks January 2000
1. Fairness (by policing how different packet streams utilize
available bandwidth),
2. Throughput (by improving the transmitter's radio
utilization).
For example, fairness is necessary for interactive applications (
telnet or web browsing) to coexist with bulk transfer sessions
Proposals here include
- Fair Queueing (FQ) [Demers90]
- Class-based Queueing (CBQ) [Floyd95]
Even if they are only implemented over the wireless link portion
the communication path, these proposals are attractive in
LTN environments, because new connections for
applications can have difficulty starting when a bulk TCP
has already stabilized using all available bandwidth
In our base architecture described above, the mobile device
communicates directly with only one wireless peer at a given time
the intermediate node. In some W-WANs, it is possible to
address other mobiles within the same cell. Direct
with each such wireless peer may traverse a spatially distinct path
each of which may exhibit statistically independent radio
characteristics. Channel State Dependent Packet Scheduling (CSDP
[BBKT96] tracks the state of the various radio links (as defined
the target devices), and gives preferential treatment to
destined for radio links in a "good" state. This avoids attempting
transmit to (and expect acknowledgements from) a peer on a "bad
radio link, thus improving throughput
A further refinement of this idea suggests that both fairness
throughput can be improved by combining a wireless-enhanced CBQ
CSDP [FSS98].
Recommendation: No recommendation at this time, pending
study
4.10 Split TCP and Performance-Enhancing Proxies (PEPs
Given the dramatic differences between the wired and the
links, a very common approach is to provide some impedance
where the two different technologies meet: at the intermediate node
Montenegro, et al. Informational [Page 22]
RFC 2757 Long Thin Networks January 2000
The idea is to replace an end-to-end TCP connection with two
distinct connections: one across the wireless link, the other
its wireline counterpart. Each of the two resulting TCP
operates under very different networking characteristics, and
adopt the policies best suited to its particular medium.
example, in a specific LTN topology it may be desirable to modify
Fast Retransmit to resend after the first duplicate ack and
Recovery to not shrink the congestion window if the LTN link has
extremely long RTT, is known to not reorder packets, and is
subject to congestion. Moreover, on a long-delay link or on a
with a relatively high bandwidth-delay product it may be desirable
"slow-start" with a relatively large initial window, even larger
four segments. While these kinds of TCP modifications can
negotiated to be employed over the LTN link, they would not
deployed end-to-end over the global Internet. In LTN topologies
the underlying link characteristics are known, a various
types of performance enhancements can be employed without
operations over the global Internet
In some proposals, in addition to a PEP mechanism at the
node, custom protocols are used on the wireless link (for example
[WAP], [YB94] or [MOWGLI]).
Even if the gains from using non-TCP protocols are moderate
better, the wealth of research on optimizing TCP for wireless,
compatibility with the Internet are compelling reasons to adopt
on the wireless link (enhanced as suggested in section 5 below).
4.10.1 Split TCP
Split-TCP proposals include schemes like I-TCP [ITCP] and MTCP [YB94]
which achieve performance improvements by abandoning end-to-
semantics
The Mowgli architecture [MOWGLI] proposes a split approach
support for various enhancements at all the protocol layers, not
at the transport layer. Mowgli provides an option to replace
TCP/IP core protocols on the LTN link with a custom protocol that
tuned for LTN links [KRLKA97]. In addition, the protocol
various features that are useful with LTNs. For example, it
priority-based multiplexing of concurrent connections together
shared flow control, thus offering link capacity to
applications in a timely manner even if there are bandwidth-
background transfers. Also with this option, Mowgli preserves
socket semantics on the mobile device so that legacy applications
be run unmodified
Montenegro, et al. Informational [Page 23]
RFC 2757 Long Thin Networks January 2000
Employing split TCP approaches have several benefits as well
drawbacks. Benefits related to split TCP approaches include
following
- Splitting the end-to-end TCP connection into two parts is
straightforward way to shield the problems of the wireless
from the wireline Internet path, and vice versa. Thus, a split
approach enables applying local solutions to the local problems
the wireless link. For example, it automatically solves
problem of distinguishing congestion related packet losses on
wireline Internet and packet losses due to transmission error
the wireless link as these occur on separate TCP connections
Even if both segments experience congestion, it may be of
different nature and may be treated as such. Moreover,
disconnections of the wireless link can be effectively
from the wireline Internet
- When one of the TCP connections crosses only a single hop
link or a very limited number of hops, some or all
characteristics for the wireless TCP path are known. For example
with a particular link we may know that the link provides
delivery of packets, packets are not delivered out of order,
the link is not subject to congestion. Having this information
the TCP path one could expect that defining the TCP mitigations
be employed becomes a significantly easier task. In addition
several mitigations that cannot be employed safely over the
Internet, can be successfully employed over the wireless link
- Splitting one TCP connection into two separate ones allows
earlier deployment of various recent proposals to improve
performance over wireless links; only the TCP implementations
the mobile device and intermediate node need to be modified,
allowing the vast number of Internet hosts to continue running
legacy TCP implementations unmodified. Any mitigations that
require modification of TCP in these wireline hosts may take
too long to become widely deployed
- Allows exploitation of various application level
which may give significant performance gains (see section 4.10.2).
Drawbacks related to split TCP approaches include the following
- One of the main criticisms against the split TCP approaches
that it breaks TCP end-to-end semantics. This has
drawbacks some of which are more severe than others. The
detrimental drawback is probably that splitting the TCP
disables end-to-end usage of IP layer security mechanisms
precluding the application of IPSec to achieve end-to-
Montenegro, et al. Informational [Page 24]
RFC 2757 Long Thin Networks January 2000
security. Still, IPSec could be employed separately in each of
two parts, thus requiring the intermediate node to become a
to the security association between the mobile device and
remote host. This, however, is an undesirable or
alternative in most cases. Other security mechanisms above
transport layer, like TLS [RFC2246] or SOCKS [RFC1928], should
employed for end-to-end security
- Another drawback of breaking end-to-end semantics is that
of the intermediate node become unrecoverable resulting
termination of the TCP connections. Whether this should
considered a severe problem depends on the expected frequency
such crashes
- In many occasions claims have been stated that if TCP end-to-
semantics is broken, applications relying on TCP to
reliable data delivery become more vulnerable. This, however,
an overstatement as a well-designed application should never
rely on TCP in achieving end-to-end reliability at the
level. First, current APIs to TCP, such as the Berkeley
interface, do not allow applications to know when an
acknowledgement for previously sent user data arrives at
sender. Second, even if the application is informed of the
acknowledgements, the sending application cannot know whether
receiving application has received the data: it only knows
the data reached the TCP receive buffer at the receiving end
Finally, in order to achieve end-to-end reliability at
application level an application level acknowledgement is
to confirm that the receiver has taken the appropriate actions
the data it received
- When a mobile device moves, it is subject to handovers by
serving base station. If the base station acts as the
node for the split TCP connection, the state of both TCP
on the previous intermediate node must be transferred to the
intermediate node to ensure continued operation over the split
connection. This requires extra work and causes overhead. However
in most of the W-WAN wireless networks, unlike in W-LANs, the W
WAN base station does not provide the mobile device with
connection point to the wireline Internet (such base stations
not even have an IP stack). Instead, the W-WAN network takes
of the mobility and retains the connection point to the
Internet unchanged while the mobile device moves. Thus, TCP
handover is not required in most W-WANs
- The packets traversing through all the protocol layers up
transport layer and again down to the link layer result in
overhead at the intermediate node. In case of LTNs with
Montenegro, et al. Informational [Page 25]
RFC 2757 Long Thin Networks January 2000
bandwidth, this extra overhead does not cause serious
performance problems unlike with W-LANs that typically have
higher bandwidth
- Split TCP proposals are not applicable to networks with
routing. Deploying a split TCP approach requires that traffic
and from the mobile device be routed through the
node. With some networks, this cannot be accomplished, or
requires that the intermediate node is located several hops
from the wireless network edge which in turn is unpractical
many cases and may result in non-optimal routing
- Split TCP, as the name implies, does not address problems
to UDP
It should noted that using split TCP does not necessarily
simultaneous usage of IP for end-to-end connectivity. Correct
of split TCP should be managed per application or per connection
should be under the end-user control so that the user can
whether a particular TCP connection or application makes use of
TCP or whether it operates end-to-end directly over IP
Recommendation: Split TCP proposals that alter TCP semantics are
recommended. Deploying custom protocols on the wireless link, such
MOWGLI proposes is not recommended, because this note
preference to (1) improving TCP instead of designing a
protocol and (2) allowing end-to-end sessions at all times
4.10.2 Application Level
Nowadays, application level proxies are widely used in the Internet
Such proxies include Web proxy caches, relay MTAs (Mail
Agents), and secure transport proxies (e.g., SOCKS). In effect
employing an application level proxy results in a "split
connection" with the proxy as the intermediary. Hence, some of
problems present with wireless links, such as combining of
congested wide-area Internet path with a wireless LTN link,
automatically alleviated to some extent
The application protocols often employ plenty of (unnecessary)
trips, lots of headers and inefficient encoding. Even
data may get delivered over the wireless link in regular
protocol operation. In many cases a significant amount of
overhead can be reduced by simply running an application level
on the intermediate node. With LTN links, significant
improvement can be achieved by introducing application level
with application-specific enhancements. Such a proxy may employ
enhanced version of the application protocol over the wireless link
Montenegro, et al. Informational [Page 26]
RFC 2757 Long Thin Networks January 2000
In an LTN environment enhancements at the application layer
provide much more notable performance improvements than any
level enhancements
The Mowgli system provides full support for adding application
agent-proxy pairs between the client and the server, the agent on
mobile device and the proxy on the intermediate node. Such a pair
be either explicit or fully transparent to the applications, but
is, at all times, under the end-user control. Good examples
enhancements achieved with app