[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
Internet Engineering Task Force                            G. Montenegro
INTERNET DRAFT                                    Sun Microsystems, Inc.
                                                              S. Dawkins
                                                          August 7, 1998

                   Wireless Networking for the MNCRS

Status of This Memo

   This document is an individual submission to the Internet
   Engineering Task Force (IETF). Comments should be submitted to the

   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

   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).


   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

   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

   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

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

   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

      - 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

      - 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

   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

   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

2.2 Non-IP Alternatives

   A number of non-IP alternatives aimed at wireless environments
   have been proposed. Two representative proposals are discussed

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

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

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

   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

      - Legacy mechanisms may be reused (for example congestion

      - 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

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,

   Fortunately, under selected conditions recent results using packet
   inter-arrival times measured at the receiver are encouraging

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

      - 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

   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

   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

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

   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

      - Allow using small packets for delay sensitive low data-rate

      - 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

   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

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

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

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

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

Delayed Duplicate      Not stable       WR            When stable
Acknowledgements                        BS (for

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

      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.

      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

      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

   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

         - 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

   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

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

   [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

   [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:

   [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


   [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

   [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.

   [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
          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]