Internet Engineering Task Force G. Montenegro
INTERNET DRAFT Sun Microsystems, Inc.
S. Dawkins
Nortel
August 7, 1998
Wireless Networking for the MNCRS
draft-montenegro-mncrs-00.txt
Status of This Memo
This document is an individual submission to the Internet
Engineering Task Force (IETF). Comments should be submitted to the
authors.
Distribution of this memo is unlimited.
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as ``work in
progress.''
To view the entire list of current Internet-Drafts, please check
the "1id-abstracts.txt" listing contained in the Internet-Drafts
Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
(Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au
(Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu
(US West Coast).
Abstract
In view of the unpredictable and problematic nature of wireless
networks, arriving at an optimized wireless transport is a
daunting task. We have reviewed the existing proposals along with
future research items. Based on this overview, we also recommend
mechanisms for implementation in long thin networks.
Montenegro,Dawkins Expires February 12, 1999 [Page 1]
INTERNET DRAFT Wireless Networking for the MNCRS August 1998
Table of Contents
1 Introduction .................................................... 3
1.1 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 MOWGLI ................................................ 9
2.2.3 Deploying Non-IP Alternatives ......................... 9
2.3 IP-based Alternatives ...................................... 9
2.3.1 Path MTU Discovery .................................... 9
2.3.2 Non-TCP Proposals ..................................... 10
3 TCP or Not ...................................................... 10
4 Optimizing TCP .................................................. 11
4.1 TCP: Current Mechanisms .................................... 11
4.1.1 Slow Start and Congestion Avoidance ................... 11
4.1.2 Fast Retransmit and Fast Recovery ..................... 12
4.2 Connection Setup with T/TCP [RFC1397, RFC1644] ............. 12
4.3 Slow Start Proposals ....................................... 13
4.3.1 Larger Initial Window ................................. 13
4.3.2 Handling Acknowledgments During Slow Start ............ 13
4.3.3 Terminating Slow Start ................................ 14
4.4 ACK Spacing ................................................ 14
4.5 Delayed Duplicate Acknowlegements .......................... 14
4.6 Selective Acknowledgements [RFC2018] ....................... 14
4.7 Detecting Corruption Loss .................................. 15
4.7.1 Without Explicit Notification ......................... 15
4.7.2 With Explicit Notification ............................ 15
4.8 Active Queue Management .................................... 15
4.9 Scheduling Algorithms ...................................... 16
4.10 Spoofing, Split TCP and Performance-Enhancing Proxies
(PEPs) ............................................................ 17
4.11 Header Compression Alternatives ........................... 19
4.12 IP Payload Compression .................................... 19
5 Candidate TCP Optimizations for MNCRS Devices ................... 20
6 Conclusion ...................................................... 25
7 Acknowledgements ................................................ 25
8 References ...................................................... 25
Author address .................................................... 30
Montenegro,Dawkins Expires February 12, 1999 [Page 2]
INTERNET DRAFT Wireless Networking for the MNCRS August 1998
1 Introduction
Optimized wireless networking is one of the major hurdles that
Mobile Computing must solve if it is to enable ubiquitous access
to networking resources. However, current data networking
protocols have been optimized primarily for wired networks.
Wireless environments have very different characteristics in terms
of latency, jitter, and error rate as compared to wired networks.
Accordingly, traditional 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,
Ricochet, CDMA, PHS, DoCoMo, GSM to name a few). W-WANs present
the most serious challenge given that the length of the wireless
link (expressed as the delay*bandwidth product) is typically 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
about 2 ms. and the bandwidth is 1 Mbps, the delay*bandwidth
product is 2000 bits. For a W-WAN such as Ricochet, a typical
round-trip time may be around 500 ms. (the best is about 230 ms.),
and the bandwidth is about 20 Kbps. This yields a delay*bandwidth
product roughly equal to 10000 bits. This value is larger than the
default 8KB buffer space used by many TCP implementations. This
means that, whereas for W-LANs the default buffer space is enough,
W-WANs will operate inefficiently (that is, they will not be able
to fill the pipe) unless they override the default value.
Most importantly, latency across a link adversely affects
throughput. For example, [MSMO97] derives an upper bound on TCP
throughput. Indeed, the resultant expression is inversely related
to the round-trip time.
The long latencies also push the limits (and commonly transgress
them) for what is acceptable to users of interactive
applications.
As a quick glance to our list of references will reveal, there is
a wealth of proposals that attempt to solve the wireless
networking problem. In this document, we survey the different
solutions available or under investigation, and issue the
corresponding recommendations.
The subsequent sections include solutions:
- unrelated to IP
- built on top of IP
Montenegro,Dawkins Expires February 12, 1999 [Page 3]
INTERNET DRAFT Wireless Networking for the MNCRS August 1998
- built on top of UDP
- built on top of TCP (modifying TCP)
There is a large body of work on the subject of improving TCP
performance over satellite links. The documents that the tcpsat
working group of the IETF is working on [AG98, AGGHSSTT98] are
very relevant. In both cases, it is essential to start by
improving the characteristics of the medium by using forward error
correction (FEC) at the link layer to reduce the BER (bit error
rate) from values as high as 10-3 to 10-6 or better. This makes
the BER manageable. Once in this realm, retransmissions schemes
(ARQ) may be used to bring it down to zero. Notice that sometimes
it may be desireable to forgo ARQ because of the additional delay
it implies. In particular, time sensitive traffic (video, audio)
must be delivered within a certain time limit beyond which the
data is obsolete. Exhaustive retransmissions in this case merely
succeed in wasting time in order to deliver data that will be
discarded once it arrives at its destination. This points at the
desireability of augmenting the protocol stack implementation on
devices such that the upper protocol layers can inform the lower
link and MAC layer when to avoid such costly retransmission
schemes.
Networks that include satellite links are examples of "long fat
networks" (LFNs or "elephants"). They are "long" networks because
their round-trip time is quite high (for example, 0.5 sec and
higher for geosynchronous satellites). Not all satellite links
fall within the LFN regime. In particular, round-trip times in a
low-earth orbiting (LEO) satellite network may be as little as a
few milliseconds (and never extend beyond 160 to 200 ms). W-WANs
share the "L" with LFNs. However, satellite networks are also
"fat". In the sense that they may have high bandwidth. Satellite
networks may often have a delay*bandwidth product above 64 KBytes,
in which case they pose additional problems to TCP [TCPHP]. W-WANs
do not generally exhibit this behavior. Accordingly, this document
only deals with wireless links that are "long, thin pipes", and
the networks that contain them: "long, thin networks". We call
these "LTNs". Strictly speaking, LTNs do not necessarily imply
wireless. However, in this document, the term LTN is used as a
synonym of "long, thin wireless networks".
This document does not give an overview of the API used to access
the underlying transport. We believe this is an orthogonal issue,
even though some of the proposals below have been put forth
assuming a given interface. Nevertheless, it is possible, for
example, to support the traditional socket semantics without
Montenegro,Dawkins Expires February 12, 1999 [Page 4]
INTERNET DRAFT Wireless Networking for the MNCRS August 1998
relying on an underlying IP network [MOWGLI].
Our focus is on the on-the-wire protocols. We try to include the
most relevant ones and briefly (given that we provide the
references needed for further study) mention their most salient
points. Our objective is to specify a collection of mechanisms for
implementation by MNCRS devices. Given that the MNCRS is an
industry consortium, the primary concern is that the
recommendations be practical, well understood, that they limit
modifications to only those devices under MNCRS control (mobile
devices and the base station or proxy), that they cover the most
common cases, and, most importantly, that they (at least an
effective subset) be deployable within the near term (6 months or
so).
1.1 Architecture
Given our focus on mobile wireless applications, we only consider
a very specific architecture that includes:
- a wireless mobile device, connected via
- a wireless link (which may, in fact comprise several hops at
the link layer), to
- a base station (sometimes referred to as an intermediate
agent) connected via
- a wireline link, which in turn interfaces with
- the landline internet and millions of legacy servers and web
sites.
Specifically, we are not as concerned with paths that include two
wireless segments separated by a wired one. This may occur, for
example, if one mobile device connects across its immediate
wireless segment via a base station to the internet, and then via
a second wireless segment to another mobile device. Most often,
mobile devices connect to a legacy server on the wired internet.
Typically, the endpoints of the wireless segment are the base
station and the mobile device. However, the latter may be a
wireless router to a mobile network. This is also important and
has applications in, for example, disaster recovery.
Our target architecture has implications which concern the
deployability of candidate solutions. In particular, an important
Montenegro,Dawkins Expires February 12, 1999 [Page 5]
INTERNET DRAFT Wireless Networking for the MNCRS August 1998
requirement is that we cannot alter the networking stack on the
legacy servers. It would be preferrable to only change the
networking stack at the base station, although changing it at the
mobile devices is certainly an option and perhaps a necessity.
We envision mobile devices that can use the wireless medium very
efficiently, but are not constrained by it. That is, full mobility
implies that the devices have the flexibility and agility to use
whichever happens to be the best network connection available at
any given point in time or space. Accordingly, devices could
switch from a wired office LAN and hand over their ongoing
connections to continue on, say, a wireless WAN. (This type of
agility also requires Mobile IP [RFC2002].)
1.2 Assumptions about the Radio Link
The system architecture described above assumes at most one
wireless link (perhaps comprising more than one wireless hop).
However, this is not enough to characterize a wireless link. Given
that this has Additional considerations are:
- What are the error characteristics of the wireless medium?
The link may present a higher BER than a wireline network in
the form of random errors. It may also have burst errors and
disconnections. The techniques below usually do not address
all the issues. Accordingly, a complete solution should
combine the best of all the proposals. Nevertheless, in this
document we are more concerned with, and give preference to
solving the most typical case: higher BER due to random
errors (and higher delays due to link-layer error corrections
and retransmissions) rather than an interruption in service
due to a handoff or a disconnection. Nevertheless, these are
also important and we do include relevant proposals in this
survey.
- Is the wireless service datagram oriented, or is it a virtual
circuit? Currently, switched virtual circuits are more
common, but packet networks are starting to appear (for
example, Metricom's Starmode [CB96], CDPD, and in the future,
GSM's GPRS.
- What kind of reliability does the link provide? Wireless
services typically retransmit a packet until it has been
acknowledged by the target. They may allow the user to turn
off this behavior. For example, GSM allows RLP (Reliable Link
Protocol) to be turned off. Metricom has a similar
"lightweight" mode.
Montenegro,Dawkins Expires February 12, 1999 [Page 6]
INTERNET DRAFT Wireless Networking for the MNCRS August 1998
- Does the mobile device transmit and receive at the same time?
Doing so increases the cost of the electronics on the mobile
device. Typically, this is not the case. We assume so in this
document.
- Does the mobile device directly address more than one peer on
the wireless link? Packets to each different peer traverse
spatially distinct wireless paths. Accordingly, the path to
each peer may exhibit very different characteristics. Quite
commonly, the mobile device addresses only one peer (the base
station) at any given point in time. When this is not the
case, techniques such as Channel-State Dependent Packet
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 network
protocol or not. In particular, some data protocols evolved from
wireless telephony are not layered on top of IP [MOWGLI, WAP].
This might make sense if the mobile device is guaranteed to talk
always through the base station. However, we expect many wireless
mobile devices to utilize wireline networks when they are
available. This model closely follows current laptop usage
patterns, where devices utilize dial-up access when "out of the
office", but utilize LANs when they are available.
For these devices, an architecture that assumes IP is the best
approach, because it will be required for communications that do
not traverse the base station (for example, upon reconnection to a
W-LAN or a 10BaseT network at the office).
2.1 Underlying Network Error Characteristics
The decision to use IP as the underlying network protocol implies
a certain (low) level of link robustness that is expected of
wireless links.
IP, and the protocols that are carried in IP packets, are
protected end-to-end by checksums that are relatively weak (and,
in some cases, optional). For much of the internet, these
checksums are sufficient; in wireless environments, the error
characteristics of the raw wireless link are much less robust than
the rest of the end-to-end path. This makes end-to-end detection
of network errors undesirable, because damaged IP packets are
Montenegro,Dawkins Expires February 12, 1999 [Page 7]
INTERNET DRAFT Wireless Networking for the MNCRS August 1998
propagated through the network only to be discarded at the
destination host, and suggests that link-level mechanisms should
be used to detect and correct transmission errors over these
links.
The right approach is to use link-layer mechanisms such as FEC,
retransmissions, and so on in order to improve the characteristics
of 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 of
Point-to-Point Protocol (PPP), with robust framing and 16-bit
checksumming, on wireline networks as a replacement for the Serial
Line Interface Protocol (SLIP), with only a single framing byte
and no checksumming.
Notice that the link-layer could adapt its frame size to the
prevalent BER. It would perform its own fragmentation and
reassembly so that IP could still enjoy a large enough MTU size
[LS98].
A common concern for using IP as a transport is the header
overhead it implies. Typically, the underlying link-layer appears
as PPP [RFC1661] to the IP layer above. This allows for header
compression schemes [IPHC, IPHC-PPP] which greatly alleviate the
problem.
2.2 Non-IP Alternatives
A number of non-IP alternatives aimed at wireless environments
have been proposed. Two representative proposals are discussed
here.
2.2.1 WAP
WAP [WAP] is an architecture designed by and primarily oriented
towards data-enabled wireless telephony devices. Instead of IP or
HTTP, WAP has alternate optimized protocols and relies on the base
station or intermediate agent to provide the impedance matching
with the internet. It currently seems to be tied primarily to GSM,
even though there is an intent to specify its operation over other
technologies such as CDMA, CDPD and US-TDMA). Since, it requires
the use of a WAP proxy, if the device switches to a legacy lan
(for example, on 10BaseT) and connects directly to a legacy
server, it would have to do so over TCP/IP.
Montenegro,Dawkins Expires February 12, 1999 [Page 8]
INTERNET DRAFT Wireless Networking for the MNCRS August 1998
2.2.2 MOWGLI
MOWGLI [MOWGLI] was an earlier research project, aimed at
higher-end devices than WAP targets. (The "MOW" in MOWGLI stands
for "Mobile Office Workstations".) MOWGLI also specifies its own
underlying transport, but it does seek to preserve the socket
semantics.
2.2.3 Deploying Non-IP Alternatives
IP is such a fundamental element of the internet that non-IP
alternatives face substantial obstacles to deployment, because
they do not exploit the IP infrastructure. Any non-IP alternative
that is used to provide gatewayed access to the internet must map
between IP addresses and non-IP addresses, must terminate IP-level
security at a gateway, and cannot use IP-oriented discovery
protocols (Dynamic Host Configuration Protocol, Domain Name
Services, Lightweight Directory Access Protocol, etc.) without
translation at a gateway.
Non-IP alternatives face the burden of proof that IP is so
ill-suited to a wireless environment that it is not a viable
technology.
2.3 IP-based Alternatives
Given its worldwide deployment, IP is an obvious choice for the
underlying network technology. Optimizations implemented at this
level benefit traditional internet application protocols as well
as new ones layered on top of IP or UDP.
2.3.1 Path MTU Discovery
Path MTU discovery benefits any protocol built on top of IP. It
allows a sender to determine what the maximum end-to-end
transmission unit is to a given destination. Withouth Path MTU
discovery, the default MTU size is 512. The benefits of using a
larger MTU are:
- Smaller ratio of header overhead to data
- Allows TCP to grow its congestion window faster, since it
increases in units of segments.
Of course, for a given BER, a larger MTU has a correspondingly
Montenegro,Dawkins Expires February 12, 1999 [Page 9]
INTERNET DRAFT Wireless Networking for the MNCRS August 1998
larger probability of error within any given segment. The BER may
be reduced using lower level techniques like FEC and link-layer
retransmissions. The issue is that now delays may become a problem
due to the additional retransmissions, and the fact that packet
transmission time increases with a larger MTU.
2.3.2 Non-TCP Proposals
Other proposals assume an underlying IP datagram service, and
implement an optimized transport either directly on top of IP
[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 could be argued that the internet has not collapsed because its
main protocol, TCP, is very careful in how it uses the network,
and generally treats it as a black box assuming all packet losses
are due to congestion and prudently backing off. This avoids
further congestion.
However, in the wireless medium, packet losses may also be due to
corruption due to high BER, fading, and so on. Here, the right
approach is to try harder, instead of backing off. Alternative
transport protocols are:
- NETBLT [NETBLT, RFC1986, RFC1030]
- MNCP [MNCP]
- ESRO [RFC2188]
- RDP [RFC908, RFC1151]
- VMTP [VMTP]
3 TCP or Not
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 in
the presence of significant levels of non-congestion loss.
TCP detractors argue that the wireless medium is one such
case, and that it is hard enough to fix TCP. They argue that
it is easier to start from scratch.
- TCP has too much header overhead.
Montenegro,Dawkins Expires February 12, 1999 [Page 10]
INTERNET DRAFT Wireless Networking for the MNCRS August 1998
- By the time the mechanisms are in place to fix it, TCP is
very heavy, and ill-suited for use by lightweight, portable
devices.
and here are some in support of TCP:
- It is preferrable to continue using the same protocol that
the rest of the Internet uses because of compatibility
reasons. Any extensions specific to the wireless link may be
negotiated.
- Legacy mechanisms may be reused (for example congestion
control)
- Link-layer FEC and ARQ can reduce the BER such that any
losses TCP does see are, in fact, caused by congestion.
Modern W-WAN technologies do this (CDPD, US-TDMA, CDMA, GSM),
thus improving TCP throughput.
- Handoffs among different technologies are made possible by
Mobile IP [RFC2002], but only if the same protocols, namely
TCP/IP, are used throughout.
- Given TCP's wealth of research and experience, alternative
protocols are relatively immature, and the full implications
of their widespread deployment, not clearly understood.
4 Optimizing TCP
There is a large volume of work on the subject of optimizing TCP
for operation over wireless media. Even though satellite networks
generally fall in the LFN regime, our current LTN focus has much
to benefit from it. For example, the work of the
TCP-over-Satellite working group of the IETF has been extremely
helpful in preparing this section [AG98, AGGHSSTT98].
4.1 TCP: Current Mechanisms
A TCP sender adapts its use of bandwidth based on feedback from
the receiver. The high latency characteristic of LTNs implies that
adaptation is correspondingly slower.
4.1.1 Slow Start and Congestion Avoidance
Slow Start and Congestion Avoidance [RFC2001] are the basis for
Montenegro,Dawkins Expires February 12, 1999 [Page 11]
INTERNET DRAFT Wireless Networking for the MNCRS August 1998
TCP's successful deployment throughout the internet. However there
are two reasons why the wireless medium adversely affects them:
- Slow start is invoked whenever a loss is detected, assuming
the network is congested. This is why it is important to
minimize the losses caused by corruption, leaving only those
that TCP expects.
- The sender increases its window based on the number of ACKs
received. This rate, of course, is dependent on the RTT
(round-trip-time) between sender and receiver, which implies
long delays in high latency links like LTNs.
- During slow start, the sender increases its window in units
of segments. This is why it is important to use an
appropriately large MTU.
4.1.2 Fast Retransmit and Fast Recovery
Fast retransmit [RFC2001] allows the receiver to inform the sender
(by sending several duplicate ACKs) of a lost segment. The sender
retransmits what it considers to be this lost segment without
waiting for the full timeout. This saves time.
After a fast retransmit, a sender invokes the fast recovery
[RFC2001] algorithm, whereby it invokes congestion avoidance, but
not slow start. This also saves time.
4.2 Connection Setup with T/TCP [RFC1397, RFC1644]
TCP engages in a "three-way handshake" whenever a new connection
is set up. Data transfer is only possible after this phase has
completed successfuly. T/TCP allows data to be exchanged in
parallel with the connection set up, saving valuable time for long
delay networks.
T/TCP clearly has benefits in some environments. We believe T/TCP
would not provide significant benefits in the environments we are
designing for because:
- Bypassing the TCP three-way handshake is only possible after
the first time a client host has connected to a server host.
- If the applications running on the mobile host are
HTTP-based, many of the benefits of T/TCP are also available
in HTTP/1.1 with persistent connections.
Montenegro,Dawkins Expires February 12, 1999 [Page 12]
INTERNET DRAFT Wireless Networking for the MNCRS August 1998
4.3 Slow Start Proposals
Because slow start dominates the network response seen by
interactive users at the beginning of a TCP connection, a number
of proposals have been made to modify or or eliminate slow start
in long latency environments.
Stability of the internet is paramount, so these proposals must
demonstrate that they will not adversely affect internet
congestion levels in significant ways. The needs of the many
outweigh the needs of the few.
4.3.1 Larger Initial Window
Full slow start, with an initial window of one segment, is a
time-consuming bandwidth adaptation procedure over LTNs. Recent
proposals suggest starting off with an initial window larger than
one segment [FAP98, SP97, AHO98].
In current simulations with an initial window of two segments,
this proposal does not contribute significantly to packet drop
rates, and it has the added benefit of improving initial response
times when the peer device delays acknowledgements during slow
start (see next proposal).
We expect the IETF tcp-impl working group to recommend allowing an
initial window of at least two segments, and perhaps as many as
four, in the near future, in environments where this significantly
improves performance (LFNs and LTNs).
4.3.2 Handling Acknowledgments During Slow Start
The sender increases its window based on the flow of ACKs coming
back from the receiver. Particularly during slow- start, this flow
is very important. A couple of the proposals that have been
studied are [Allman98]:
- Make each ACK count to its fullest by growing the window
based on the data being acknowledged (byte counting) instead
of the number of ACKs (ACK counting). This has been shown to
cause bursts which lead to congestion. [Allman98] shows that
Limited Byte Counting (LBC), in which the window growth is
limited to 2 segments, does not lead to burstiness, and
offers some performance gains.
- Keep a constant stream of ACKs coming back by turning off
Montenegro,Dawkins Expires February 12, 1999 [Page 13]
INTERNET DRAFT Wireless Networking for the MNCRS August 1998
delayed ACKs [RFC1122], at least during slow-start.
4.3.3 Terminating Slow Start
New mechanisms [AGGHSSTT98] are being proposed to improve TCP's
adaptive properties such that the available bandwidth is better
utilized and at the same time reducing the possibility of
congesting the network. The latter leads to the closing of the
congestion window to 1 segment, and the subsequent slow-start
phase.
4.4 ACK Spacing
During slow-start, the sender responds to the incoming ACK stream
by transmitting two new segment for each ACK received. This
results in data being sent at twice the speed at which it can be
processed by the network. Accordingly, queues will form, and due
to lack of sufficient buffering at the bottleneck router, packets
may get dropped before the link's capacity is full. Spacing out
the ACKs effectively controls the rate at which the sender will
transmit into the network, and may result in little or no queueing
at the bottleneck router [ACKSPACING].
4.5 Delayed Duplicate Acknowlegements
As was mentioned above, link-layer retransmissions may raise the
BER such that congestion accounts for most of the packet losses
(still, nothing can be done about interruptions due to handoffs,
moving beyond wireless coverage, etc). In this scenario, it is
imperative to prevent interaction between link-layer
retransmission and TCP retransmission as these layers duplicate
each other's efforts. In such an environment it may make sense to
delay TCP's efforts so as to give the link-layer a chance to
recover [MV97]. It is preferrable to allow a local mechanism to
resolve a local problem, instead of invoking TCP's end-to-end
mechanism and incurring the associated costs, both in terms of
wasted bandwidth and in terms of its effect on TCP's window.
4.6 Selective Acknowledgements [RFC2018]
The applicability of SACK is suspect, according to Section 1.1 of
[TCPHP]. In particular, SACK may be useful in the LFN regime,
specially if large windows are being used, because there is a
considerable probability of multiple segment losses per window. In
Montenegro,Dawkins Expires February 12, 1999 [Page 14]
INTERNET DRAFT Wireless Networking for the MNCRS August 1998
the LTN regime, windows are not larger than the usual, and
single-segment losses will be, by far, the most common.
Accordingly, the complexity of SACK may not be justifiable, unless
there is a high probability of burst errors and congestion on the
wireless link.
Berkeley's Snoop protocol research [SNOOP] indicates that SACK
does improve throughput for Snoop when multiple segments are lost
per window [BPSK96].
4.7 Detecting Corruption Loss
4.7.1 Without Explicit Notification
In the absence of explicit notification from the network, some
researchers have suggested statistical methods for congestion
avoidance [Jain89, WC91, VEGAS]. A natural extension of these
heuristics would enable a sender to distinguish between losses
caused by congestion and other causes. Unfortunately, it does not
seem like these sender-based heuristics are at all reliable [BV97,
BV98].
Fortunately, under selected conditions recent results using packet
inter-arrival times measured at the receiver are encouraging
[BV98a].
4.7.2 With Explicit Notification
Explicit notification from the network can make it very easy to
determine when a loss is not due to congestion, so as to avoid
invoking TCP's costly recovery mechanism. Several proposals along
these lines include:
- ELN [BPSK96]
- EBSN [BBKVP96]
- ELNR, and EDDAN (notifications to mobile receiver) [MV97]
- ECN [ECN]
4.8 Active Queue Management
As has been pointed out above, TCP responds to congestion by
Montenegro,Dawkins Expires February 12, 1999 [Page 15]
INTERNET DRAFT Wireless Networking for the MNCRS August 1998
closing down the window and invoking slow-start. Long-delay
networks take a particularly long time to recover from this
condition. Accordingly, it is imperative to avoid congestion in
LTNs. To remedy this, active queue management techniques have been
proposed as enhancements to routers throughout the Internet [RED].
The primary motivation for deployment of these mechanisms is to
prevent "congestion collapse" (a severe degradation in service) by
controlling the average queue size at the routers. As the average
queue length grows, Random Early Detection [RED] increases the
possibility of dropping packets.
The benefits are:
- Reduce packet drops in routers. By dropping a few packets
before severe congestion sets in, RED avoids dropping bursts
of packets.
- Provide lower delays. This follows from the smaller queue
sizes, and is particularly important for interactive
applications, for which the inherent delays of wireless links
already push the user experience to the limits of the
non-acceptable.
- Avoid lock-outs. Packets from over-agressive flows can get
dropped with the same probability as other packets.
4.9 Scheduling Algorithms
Active queue management helps control the length of the queues.
Additionally, a general solution requires replacing FIFO with
other scheduling algorithms that improve:
1. Fairness (by policing how different packet streams utilize
the available bandwidth), and
2. Throughput (by improving the transmitter's radio channel
utilization).
For example, fairness is necessary for interactive applications
(like telnet or web browsing) to coexist with bulk transfer
sessions. Proposals here include:
- Fair Queueing (FQ) [Demers90]
- Class-based Queueing (CBQ) [Floyd95]
These proposals may be attractive in wireless LTN environments,
Montenegro,Dawkins Expires February 12, 1999 [Page 16]
INTERNET DRAFT Wireless Networking for the MNCRS August 1998
even if they are only implemented over the wireless link portion
of the communication path, because new connections for interactive
applications can have difficulty starting when a bulk TCP transfer
has already stabilized using all available bandwidth.
In our base architecture described above, the mobile device
typically communicates directly with only one wireless peer at a
given time: the base station. However, it is possible to directly
address other mobiles within the same cell. Direct communication
with each such wireless peer traverses a spatially distinct path,
each of which exhibits statistically independent radio link
characteristics. Channel State Dependent Packet Scheduling (CSDP)
[BBKT96] tracks the state of the various radio links (as defined
by the target devices), and gives preferential treatment to
packets destined for radio links in a "good" state. This avoids
attempting to transmit to (and to elicit acknowledgements from) a
peer on a "bad" radio link, thus improving throughput.
A further refinement of this idea suggests that both fairness and
throughput can be achieved by combining a wireless-enhanced CBQ
with CSDP [FSS98].
4.10 Spoofing, Split TCP and Performance-Enhancing Proxies (PEPs)
Given the dramatic differences between the wired and the wireless
links, a very common approach is to provide some impedance
matching where the two different technologies meet: at the base
station.
The idea is to replace an end-to-end TCP connection with two
clearly distinct connections: one across the wireless link, the
other across its wireline counterpart. Each of the two resulting
TCP sessions operates under very different networking
characteristics, and may adopt the policies best suited to its
particular medium. For example, in an extreme case it may be
desirable to turn off Fast Retransmission and Fast Recovery only
on the wireless TCP link, because on this portion of the
connection path, losses may be caused almost exclusively by
corruption instead of congestion.
Spoofing proposals include schemes like I-TCP [ITCP] which
achieves performance improvements by relinquishing end-to-end
semantics. [MTCP] alleviates this problem somewhat, but does not
entirely solve it.
Berkeley's Snoop protocol [SNOOP] is a hybrid scheme mixing
link-layer reliability mechanisms with the split connection
Montenegro,Dawkins Expires February 12, 1999 [Page 17]
INTERNET DRAFT Wireless Networking for the MNCRS August 1998
approach. It is an improvement over I-TCP in that end-to-end
semantics are retained as well as in terms of performance. Snoop
does two things:
1. Locally (on the wireless link) retransmit lost packets,
instead of allowing TCP to do so end-to-end.
2. Suppress the duplicate acks on their way from the receiver
back to the sender, thus avoiding fast retransmit and
congestion avoidance at the latter.
WTCP [WTCP] is similar to Snoop in that it preserves end-to-end
semantics. In WTCP, the base station uses a complex scheme to
hide the time it spends moving packets across the wireless link
(this typically includes retransmissions due to error recovery,
but may also include time spent dealing with congestion). In order
to work effectively, it assumes that the TCP endpoints implement
the Timestamps option in RFC 1323 [TCPHP]. Unfortunately, support
for RFC 1323 in TCP implementations is not yet widespread. Beyond
this, WTCP requires changes only at the base station.
All of these schemes require the base station to examine and
operate on the traffic between the portable wireless device and
the TCP server on the wired Internet. None of these work if the IP
traffic is encrypted, unless, of course, the base station is privy
to the security association between the mobile device and its
end-to-end peer. They also require that both the data and the
corresponding ACKs traverse the same base station. Furthermore,
if the base station retransmits packets at the transport layer
across the wireless link, this may duplicate efforts by the
link-layer. Snoop has been described by its designers as a
TCP-aware link-layer. This is the right approach: layers 2 and 3
should be integrated much more tightly than traditional OSI
layering suggests.
Often, in addition to the PEP mechanism at the base station, a
custom protocol is used on the wireless link (for example, [WAP]
or [MOWGLI]). However, there is evidence that the performance
gains are due to the fact that a proxy serves as a coupling device
between the wireless and wireline worlds, and that using a custom
protocol on the wireless link only affords limited benefits
[YB94]. Even if the gains were moderate or better, the wealth of
research on optimizing TCP for wireless, and compatibility with
the Internet are overwhelmingly compelling reasons to adopt TCP on
the wireless link (of course, enhanced as suggested in section 5
below).
Montenegro,Dawkins Expires February 12, 1999 [Page 18]
INTERNET DRAFT Wireless Networking for the MNCRS August 1998
4.11 Header Compression Alternatives
Because Long Thin Networks are bandwidth-constrained, every byte
that can be compressed out of over-the-air segments is worth
compressing.
Van Jacobson header compression [RFC1144] describes a Proposed
Standard for TCP Header compression that is widely deployed.
Mechanisms for TCP and IP header compression defined in [IPHC,
IPHC-PPP] provide the following benefits:
- Improve interactive response time
- Allow using small packets for bulk data with good line
efficiency
- Allow using small packets for delay sensitive low data-rate
traffic
- Decrease header overhead (for the smallest MTU of 512 the
header overhead of TCP over IP falls from 11.7 to less than 1
per cent.
- Reduce packet loss rate over lossy links.
4.12 IP Payload Compression
Compression of IP segment payloads is also desirable. "IP Payload
Compression Protocol (IPComp)" [IPCOMP] defines a framework where
common compression algorithms can be applied to arbitrary IP
segment payloads. IP payload compression is something of a niche
optimization. It is necessary because IP-level security converts
IP payloads to random bitstreams, defeating commonly-deployed
link-layer compression mechanisms which are faced with payloads
that have no redundant "information" that can be more compactly
represented.
However, many IP payloads are already compressed (images, audio,
video, "zipped" files being FTPed), or are already encrypted above
the IP layer (SSL/TLS, etc.). These payloads will not "compress"
further, limiting the benefit of this optimization.
For now, IPCOMP compression of HTML and MIME headers is an obvious
benefit.
Montenegro,Dawkins Expires February 12, 1999 [Page 19]
INTERNET DRAFT Wireless Networking for the MNCRS August 1998
5 Candidate TCP Optimizations for MNCRS Devices
The table below summarizes our recommendations with regards to the
main proposals mentioned above. The first column, "Stability of
the Proposal", refers to the maturity of the mechanism in
question. Some proposals are being pursued within the IETF in a
somewhat open fashion. IETF proposals are either Drafts
(preliminary versions) or RFCs. There are several types of RFCs.
Proposed Standards (PS) are standards track, and carry more weight
than Informational. Other proposals are isolated efforts with
little or no public review, and little chance of garnering
industry backing. "Implemented at" gives an indication of which
participant in a TCP session must be modified to implement the
proposal. Of course, legacy servers cannot be modified, so this
column merely indicates whether implementation happens at either
or both of the two nodes under MNCRS control: mobile device and
base station. The symbols used are: WS (wireless sender, that is,
the mobile device's TCP send operation must be modified), WR
(wireless receiver, that is, the mobile device's TCP receive
operation must be modified), WD (wireless device, that is,
modifications at the mobile device are not specific to either TCP
send or receive), BS (base station) and NI (network
infrastructure). The End-to-end IPSec column indicates if a given
mechanism works in the presence of IPSec encrypted traffic between
the mobile device and the server. MNCRS Adoption captures the
MNCRS recommendation. Some mechanisms are endorsed for immediate
adoption, others need more evidence and research, and others are
discarded.
Montenegro,Dawkins Expires February 12, 1999 [Page 20]
INTERNET DRAFT Wireless Networking for the MNCRS August 1998
Name Stability of Implemented MNCRS Adoption
the Proposal at
==================== ============= =========== =================
Increased Initial IETF Draft WS Yes
Congestion Window (initial_window=2)
Disable delayed ACKs NA WR When stable
during slow-start
Byte counting NA WS No
instead of ACK
counting
TCP Header RFC 1144 (PS) WD Yes
compression for PPP BS
IP Payload IETF Draft WD Yes
Compression (Approved as (simultaneously
PS) needed on Server)
IP Header IETF Draft WD Mobile IP only
Compression BS
(includes IP-IP) for
PPP
Snoop plus SACK In limited use BS Yes
WD (for SACK)
Fast retransmit/fast RFC 2001 (PS) WD Yes (should be
recovery there already)
Transaction/TCP RFC 1644 WD No
(Experimental) (simultaneously
needed on Server)
Estimating Slow NA WS No
Start Threshold
(ssthresh)
Delayed Duplicate Not stable WR When stable
Acknowledgements BS (for
notifications)
Class-based Queuing NA WD When stable
on End Systems
Montenegro,Dawkins Expires February 12, 1999 [Page 21]
INTERNET DRAFT Wireless Networking for the MNCRS August 1998
Explicit Congestion IETF Draft WD When stable
Notification NI
Of all the candidate optimizations in the table above, only Snoop
plus SACK and Delayed duplicate acknowledgements are currently
being proposed only for wireless networks. The others are being
considered even for non-wireless applications. Their more general
applicability has the benefit of drawing more attention and
analysis from the research community.
Of the above mechanisms, only Header Compression (for IP and TCP)
and "Snoop plus SACK" cease to work in the presence of IPSec.
Increased Initial Congestion Window
Implement this on MNCRS devices now. The research on this
optimization indicates that 2 is a safe initial setting and is
centering on choosing between 2, 3, and 4. For now, use 2,
which at least allows clients running query-response
applications to get an initial ACK from unmodified servers
without waiting for a delayed ACK timeout of 200-500
milliseconds.
Many of the benefits of this optimization are also available
(after the first request-response exchange) when clients and
servers both implement HTTP/1.1. This optimization works with
older servers that implement only HTTP/1.0.
Disable delayed ACKs during slow start
Implement this on MNCRS pending further investigation. Even
though simulations confirm its promise (it allows receivers to
get the second segment from unmodified senders without waiting
for a delayed ACK timeout of 200-500 milliseconds), for this
technique to be practical the receiver must acknowledge every
segment only when the sender is in slow-start. Continuing to
do so when the sender is in congestion avoidance may have
adverse effects on the mobile device's battery consumption and
on traffic in the network.
For now, the recommendation is to conservative ACK only the
first segment on a new connection with no delay.
Again, many of the benefits of this optimization are also
available after the first request-response exchange when
clients and servers both implement HTTP/1.1. This optimization
works with older servers that implement only HTTP/1.0.
Montenegro,Dawkins Expires February 12, 1999 [Page 22]
INTERNET DRAFT Wireless Networking for the MNCRS August 1998
Byte Counting instead of ACK Counting
Unlimited byte counting is not recommended.
In
http://tcpsat.lerc.nasa.gov/tcpsat/meetings/munich-minutes.txt,
Van Jacobson says that byte counting is a bad thing because it
leads to burstiness, and recommends ACK spacing instead.
Limited byte counting warrants further investigation before
deciding, but it shows promise.
TCP Header Compression for PPP
Implement this on MNCRS devices now. It is a widely-implemented
Proposed Standard.
IP Payload Compression
Recommended, as the IETF has approved it as a proposed
standard.
Notes on this optimization:
- Some payloads are already compressed, and won't be
compressed further (JPEG, GIF).
- Payloads must be compressed before encryption (encrypted
payloads won't compress).
- HTTP-NG is considering supporting compression of resources
at the HTTP level, which would provide the same benefits
for common compressible MIME types like text/html.
IP Header Compression (includes IP-IP) for PPP
Implement this on MNCRS devices when the Internet-Draft becomes
stable.
SNOOP plus SACK
Implement this on MNCRS-capable base stations now. Research
results are encouraging, and it's an "invisible" optimization -
neither the client nor the server needs to change, only the
base station (for base SNOOP).
SNOOP benefits from selective acknowledgements in order to
recover from multi-segment losses in one round-trip. In this
Montenegro,Dawkins Expires February 12, 1999 [Page 23]
INTERNET DRAFT Wireless Networking for the MNCRS August 1998
case, the mobile device needs to implement some form of
selective acknowledgements. If selective acknowledgments are
not used, recovery from multi-segment losses takes so long that
TCP enters congestion avoidance anyway.
Encryption of IP packets via IPSEC's ESP header (in either
transport or tunnel mode) renders the TCP header and payload
unintelligible to the base station. This precludes SNOOP from
working, because it needs to examine the TCP headers in both
directions. Possible solutions involve:
- making the SNOOPing base station a party to the security
association between the client and the server
- IPSEC tunneling mode, terminated at the SNOOPing base
station
- and so on.
However, at this time these are not well understood so MNCRS
users valuing both privacy and performance should use SSL or
SOCKS for end-to-end security.
Fast Retransmit/Fast Recovery
Implement on MNCRS devices at this time. It is a
widely-implemented optimization and is currently at Proposed
Standard level.
Transaction TCP (T/TCP)
Not recommended at this time, for these reasons:
- It's an Experimental RFC, and has not been advanced.
- It's not widely deployed, and it has to be deployed at
both ends of a connection.
- At least some of the benefits of T/TCP (eliminating
three-way handshake on subsequent query-response
transactions, for instance) are also available with
persistent connections on HTTP/1.1, which is more widely
deployed.
Estimating Slow Start Threshold (ssthresh)
Not recommended.
Montenegro,Dawkins Expires February 12, 1999 [Page 24]
INTERNET DRAFT Wireless Networking for the MNCRS August 1998
Rough consensus on the tcp-impl and tcp-sat mailing lists is
that there is no good way to probe during TCP startup and
estimate bandwidth available.
Delayed Duplicate Acknowledgements
Recommended, pending further research and experience.
Class-based queuing on end systems
No recommendation at this time.
Explicit Notifications
No recommendation at this time. Schemes like ELNR and EDDAN
[MV97], in which the only systems that need to be modified are
the base station and the mobile device are slated for adoption
pending further research. However, the requirement that the
base station be able to examine the TCP headers flying through
it poses the previously stated issues with respect to
IPSEC-encrypted packets.
ECN is slated for adoption when and if the IETF finalizes the
specification.
6 Conclusion
In view of the unpredictable and problematic nature of wireless
networks, arriving at an optimized wireless transport is a
daunting task. We have reviewed the existing proposals along with
future research items. Based on this overview, we also recommend
mechanisms for implementation in long thin networks.
7 Acknowledgements
The authors are deeply indebted to the IETF tcpsat and tcpimpl
working groups, and to Prof. Nitin Vaidya (Texas A&M) whose many
insightful comments have proved invaluable in our attempt at
improving this note. The following individuals have also provided
valuable feedback: Mark Allman (NASA), Raphi Rom (Technion/Sun).
8 References
[ACKSPACING] Partridge, C., "ACK Spacing for High Delay-Bandwidth
Paths with Insufficient Buffering," July 1997. Internet-Draft
Montenegro,Dawkins Expires February 12, 1999 [Page 25]
INTERNET DRAFT Wireless Networking for the MNCRS August 1998
draft-partridge-e2e-ackspacing-00.txt (work in progress).
[AG98] Mark Allman, Dan Glover. Enhancing TCP Over Satellite
Channels using Standard Mechanisms, May 1998. Internet-Draft
draft-ietf-tcpsat-stand-mech-04.txt (work in progress).
[AGGHSSTT98] Mark Allman, Dan Glover, Jim Griner, John Heidemann,
Keith Scott, Jeffrey Semke, Joe Touch, Diepchi Tran. Ongoing TCP
Research Related to Satellites, May 1998. Internet-Draft
draft-ietf-tcpsat-res-issues-03.txt (work in progress).
[Allman98] Allman, M., "On the Generation and Use of TCP
Acknowledgments," July, 1998. Submitted to ACM Computer
Communication Review.
[AHO98] Allman, M., Hayes, C., Ostermann, S., "An Evaluation of
TCP with Larger Initial Windows," Computer Communication Review,
28(3), July 1998.
[BBKT96] Bhagwat, P., Bhattacharya, P., Krishna, A., Tripathi, S.,
"Enhancing Throughput over Wireless LANs Using Channel State
Dependent Packet Scheduling," in Proc. IEEE INFOCOM'96, pp.
1133-40, March 1996.
[BBKVP96] Bakshi, B., P., Krishna, N., Vaidya, N., Pradhan, D.K.,
"Improving Performance of TCP over Wireless Networks," Technical
Report 96-014, Texas A&M University, 1996.
[BPSK96] Balakrishnan, H., Padmanabhan, V., Seshan, S., Katz, R.,
"A Comparison of Mechanisms for Improving TCP Performance over
Wireless Links," in ACM SIGCOMM, Stanford, California, August
1996.
[BV97] Biaz, S., Vaidya, N., "Using End-to-end Statistics to
Distinguish Congestion and Corruption Lossses: A Negative Result,"
Texas A&M University, Technical Report 97-009, August 18, 1997.
[BV98] Biaz, S., Vaidya, N., "Sender-Based heuristics for
Distinguishing Congestion Losses from Wireless Transmission
Losses," Texas A&M University, Technical Report 98-013, June
1998.
[BV98a] Biaz, S., Vaidya, N., "Discriminating Congestion Losses
from Wireless Losses using Inter-Arrival Times at the Receiver,"
Texas A&M University, Technical Report 98-014, June 1998.
[CB96] Cheshire, S., Baker, M., "Experiences with a Wireless
Network in MosquitoNet," IEEE Micro, February 1996. Available
Montenegro,Dawkins Expires February 12, 1999 [Page 26]
INTERNET DRAFT Wireless Networking for the MNCRS August 1998
online as:
http://rescomp.stanford.edu/~cheshire/papers/wireless.ps.
[Demers90] Demers, A., Keshav, S., and Shenker, S., Analysis and
Simulation of a Fair Queueing Algorithm, Internetworking: Research
and Experience, Vol. 1, 1990, pp. 3-26.
[ECN] Ramakrishnan, K.K., Floyd, S., "A Proposal to add Explicit
Congestion Notification (ECN) to IPv6 and to TCP", November 1997.
Internet-Draft draft-kksjf-ecn-00.txt (work in progress).
[FAP98] Mark Allman, Sally Floyd, Craig Partridge. Increasing
TCP's Initial Window, May 1998. Internet-Draft
draft-floyd-incr-init-win-03.txt (work in progress).
[Floyd95] Floyd, S., and Jacobson, V., Link-sharing and Resource
Management Models for Packet Networks. IEEE/ACM Transactions on
Networking, Vol. 3 No. 4, pp. 365-386, August 1995.
[FSS98] Fragouli, C., Sivaraman, V., Srivastava, M., "Controlled
Multimedia Wireless Link Sharing via Enhanced Class-Based Queueing
with Channel-State-Dependent Packet Scheduling," Proc. IEEE
INFOCOM'98, April 1998.
[GSM] Rahnema, M., "Overview of the GSM system and protocol
architecture," IEEE Communications Magazine, vol. 31, pp 92-100,
April 1993.
[IPCOMP] A. Shacham, R. Monsour, R. Pereira, M. Thomas, IP Payload
Compression Protocol (IPComp), May 1998. Internet-Draft
draft-ietf-ippcp-protocol-06.txt (work in progress).
[IPHC] Mikael Degermark, Bjorn Nordgren,Stephen Pink. IP Header
Compression, December 1997. Internet-Draft
draft-degermark-ipv6-hc-05.txt (work in progress).
[IPHC-PPP] Mathias Engan, S. Casner, C. Bormann. IP Header
Compression over PPP, December 1997. Internet-Draft
draft-engan-ip-compress-02.txt (work in progress).
[ITCP] Bakre, A., Badrinath, B.R., "Handoff and Systems Support
for Indirect TCP/IP. In Proceedings of the Second USENIX Symposium
on Mobile and Location-Independent Computing, Ann Arbor, Michigan,
April 10-11, 1995.
[Jain89] Jain, R., "A Delay-Based Approach for Congestion
Avoidance in Interconnected Heterogeneous Computer Networks,"
Digital Equipment Corporation, Technical Report DEC-TR-566, April
Montenegro,Dawkins Expires February 12, 1999 [Page 27]
INTERNET DRAFT Wireless Networking for the MNCRS August 1998
1989.
[LS98] Lettieri, P., Srivastava, M., "Adaptive Frame Length
Control for Improving Wireless Link Throughput, Range, and Energy
Efficiency," Proc. IEEE INFOCOM'98, April 1998.
[MNCP] Piscitello, D., Phifer, L., Wang, Y., Hovey, R., Mobile
Network Computing Protocol (MNCP), August 1997. Internet-Draft
draft-piscitello-mncp-00.txt (work in progress).
[MOWGLI] An Efficient Transport Service for Slow Wireless
Telephone Links, http://www.cs.Helsinki.FI/research/mowgli/
[MSMO97] Mathis, M., Semke, J., Mahdavi, J., Ott, T., "The
Macroscopic Behavior of the TCP Congestion Avoidance Algorithm,"
in Computer Communications Review, a publication of ACM SIGCOMM,
volume 27, number 3, July 1997.
[MTCP] Brown, K. Singh, S., "A Network Architecture for Mobile
Computing," Proc. IEEE INFOCOM'96, pp. 1388-1396, March 1996.
Available as
ftp://ftp.ece.orst.edu/pub/singh/papers/transport.ps.gz.
[MV97] Mehta, M., Vaidya, N., "Delayed
Duplicate-Acknowledgements: A Proposal to Improve Performance of
TCP on Wireless Links," Texas A&M University, December 24, 1997.
Available as http://www.cs.tamu.edu/faculty/vaidya/mobile.html
[NETBLT] John C. White, NETBLT (Network Block Transfer Protocol),
draft-white-protocol-stack-00.txt, April 1997 - work in progress.
[RED] Braden, B. Clark, D., Crowcroft, J., Davie, B., Deering, S.,
Estrin, D., Floyd, S., Jacobson, V., Minshall, G., Partridge, C.,
Peterson, L., Ramakrishnan, K.K., Shenker, S., Wroclawski, J.,
Zhang, L., Recommendations on Queue Management and Congestion
Avoidance in the Internet, February 17, 1998. Internet-Draft
draft-irtf-e2e-queue-mgt-01.txt (work in progress).
[RFC908] Velten, D., Hinden, R., Sax, J., "Reliable Data
Protocol", RFC 908, July 1984.
[RFC1030] Lambert, M., "On Testing the NETBLT Protocol over Divers
Networks", RFC 1030, November 1987.
[RFC1122] Braden, R., Requirements for Internet Hosts --
Communication Layers, October 1989.
[RFC1144] Jacobson, V., Compressing TCP/IP Headers for Low-Speed
Montenegro,Dawkins Expires February 12, 1999 [Page 28]
INTERNET DRAFT Wireless Networking for the MNCRS August 1998
Serial Links, RFC 1144, February 1990.
[RFC1151] Partridge, C., Hinden, R., Version 2 of the Reliable
Data Protocol (RDP), RFC 1151, April 1990.
[RFC1191] Jeff Mogul and Steve Deering. Path MTU Discovery,
November 1990. RFC 1191.
[RFC1397] Braden, R., Extending TCP for Transactions -- Concepts,
November 1992.
[RFC1644] Braden, R., T/TCP -- TCP Extensions for Transactions
Functional Specification, July 1994.
[RFC1661] Simpson, W., ed., "The Point-To-Point Protocol (PPP)",
RFC 1661, July 1994.
[RFC1986] Polites, W., Wollman, W., Woo, D., Langan, R.,
"Experiments with a Simple File Transfer Protocol for Radio Links
using Enhanced Trivial File Transfer Protocol (ETFTP)", RFC 1986,
August 1996.
[RFC2001] W. Richard Stevens. TCP Slow Start, Congestion
Avoidance, Fast Retransmit, and Fast Recovery Algorithms, January
1997. RFC 2001.
[RFC2002] Perkins, C., Editor, "IP Mobility Support", RFC 2002,
October 1996.
[RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and Romanow, A.,
"TCP Selective Acknowledgment Options", October, 1996.
[RFC2188] Banan, M., Taylor, M., Cheng, J., "AT&T/Neda's Efficient
Short Remote Operations (ESRO) Protocol Specification Version
1.2", RFC 2188, September 1997.
[SNOOP] Balakrishnan, H., Seshan, S., Amir, E., Katz, R.,
"Improving TCP/IP Performance over Wireless Networks," Proc. 1st
ACM Conf. on Mobile Computing and Networking (Mobicom), Berkeley,
CA, November 1995.
[SP97] Tim Shepard and Craig Partridge. When TCP Starts Up With
Four Packets Into Only Three Buffers, July 1997. Internet-Draft
draft-shepard-TCP-4-packets-3-buff-00.txt (work in progress).
[TCPHP] Van Jacobson, Robert Braden, and David Borman. TCP
Extensions for High Performance, May 1992. RFC 1323.
Montenegro,Dawkins Expires February 12, 1999 [Page 29]
INTERNET DRAFT Wireless Networking for the MNCRS August 1998
[VEGAS] Brakmo, L., O'Malley, S., "TCP Vegas, New Techniques for
Congestion Detection and Avoidance," SIGCOMM'94, London, pp 24-35,
October 1994.
[VMTP] Cheriton, D., "VMTP: Versatile Message Transaction
Protocol", RFC 1045, February 1988.
[WAP] Wireless Application Protocol Forum.
http://www.wapforum.org/
[WC91] Wang, Z., Crowcroft, J., "A New Congestion Control Scheme:
Slow Start and Search," ACM Computer Communication Review, vol 21,
pp 32-43, January 1991.
[WTCP] Ratnam, K., Matta, I., "WTCP: An Efficient Transmission
Control Protocol for Networks with Wireless Links," Technical
Report NU-CCS-97-11, Northeastern University, July 1997. Available
at: http://www.ece.neu.edu/personal/karu/papers/WTCP-NU.ps.gz
[YB94] Yavatkar, R., Bhagawat, N., "Improving End-to-End
Performance of TCP over Mobile Internetworks," Proc. Workshop on
Mobile Computing Systems and Applications, IEEE Computer Society
Press, Los Alamitos, California, 1994.
Authors' addresses
Questions about this document may be directed at:
Gabriel E. Montenegro
Sun Microsystems, Inc.
901 San Antonio Road
Mailstop UMPK 15-214
Mountain View, California 94303
Voice: +1-650-786-6288
Fax: +1-650-786-6445
E-Mail: gabriel.montenegro@eng.sun.com
Spencer Dawkins
Nortel
P.O. Box 833805
Richardson, Texas 75083-3805
Voice: +1-972-684-4827
Fax: +1-972-685-3292
E-Mail: sdawkins@nortel.com
Montenegro,Dawkins Expires February 12, 1999 [Page 30]