Subject: draft-ietf-pilc-2.5g3g-00

From: "Hiroshi INAMURA" <[email-masked]>
Date: Fri, 23 Feb 2001 17:27:54 +0900

Hi,

This is an internet draft for pilc WG document. This work is agreed in pilc
WG in San Diego metting.

Thanks,

Hiroshi Inamura
NTT DoCoMo Multimedia Labs,

--

Network Working Group                                H. Inamura (editor)
Internet-Draft                                          NTT DoCoMo, Inc.
Expires: August 23, 2001                                   G. Montenegro
                                                  Sun Microsystems, Inc.
M. Hara                                                          M. Hata
Fujitsu, Inc.                                           NTT DoCoMo, Inc.
W. Gilliam                                                      J. James
Hewlett-Packard Company                                   Motorola, Inc.
R. Ludwig                                                      A. Hameed
Ericsson Research                                       Fujitsu FNC, Inc.
P. Ford                                                        R. Garces
Microsoft                                                       Metricom
                                                                F. Wills
                                                                Openwave

                                                            Feb 22, 2001
                 TCP over 2.5G and 3G Wireless Networks
                       draft-ietf-pilc-2.5g3g-00

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other documents
   at any time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   Comments should be submitted to the PILC mailing list at
   [email-masked].
   Distribution of this memo is unlimited.

Inamura, et. al.        Expires August 23, 2001                 [Page 1]

Internet-Draft    TCP over 2.5G and 3G Wireless Networks        Feb 2001

   This Internet-Draft will expire on August 23, 2001.

Copyright Notice

   Copyright (C) The Internet Society (2001). All Rights Reserved.

Abstract

   This document describes a profile for optimizing TCP over 2.5G/3G
   networks. We describe the link characteristics of 3G wireless by
   using W-CDMA (Wideband CDMA) as an example. We then recommend TCP
   optimization mechanisms and, finally, present examples of wireless
   internet services and standardization activities. These potentially
   will deploy the profile described in this document.

Table of Contents

   1.    Introduction . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.    2.5G and 3G Link Characteristics . . . . . . . . . . . . . .  4
   3.    TCP over 2.5G and 3G . . . . . . . . . . . . . . . . . . . .  5
   3.1   Optimization Mechanisms  . . . . . . . . . . . . . . . . . .  5
   3.1.1 Large window size  . . . . . . . . . . . . . . . . . . . . .  5
   3.1.2 Large initial window . . . . . . . . . . . . . . . . . . . .  5
   3.1.3 MTU larger than default IP MTU . . . . . . . . . . . . . . .  6
   3.1.4 Path MTU discovery . . . . . . . . . . . . . . . . . . . . .  6
   3.1.5 Selective Acknowledgments  . . . . . . . . . . . . . . . . .  6
   3.1.6 Explicit Congestion Notification . . . . . . . . . . . . . .  7
   3.1.7 Summary  . . . . . . . . . . . . . . . . . . . . . . . . . .  7
   3.2   Applications . . . . . . . . . . . . . . . . . . . . . . . .  7
   3.2.1 i-mode . . . . . . . . . . . . . . . . . . . . . . . . . . .  7
   3.2.2 WAP  . . . . . . . . . . . . . . . . . . . . . . . . . . . .  8
   3.2.3 Ricochet MCDN Network  . . . . . . . . . . . . . . . . . . .  8
   4.    Open Issues  . . . . . . . . . . . . . . . . . . . . . . . . 10
   5.    Security Considerations  . . . . . . . . . . . . . . . . . . 11
         References . . . . . . . . . . . . . . . . . . . . . . . . . 12
         Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 13
         Full Copyright Statement . . . . . . . . . . . . . . . . . . 15

Inamura, et. al.        Expires August 23, 2001                 [Page 2]

Internet-Draft    TCP over 2.5G and 3G Wireless Networks        Feb 2001

1. Introduction

   Recently, much development and deployment activity has centered
   around GPRS, UMTS and IMT-2000, also referred to as 2.5G/3G wireless
   networks. Since a primary motivation for these is data
   communication, and, in particular, Internet access, TCP performance
   is a key issue.

   A number of TCP optimization techniques have been studied to enhance
   the performance of TCP transmission for various wireless
   environments.

   This document proposes a profile of such techniques, derived from
   previous work at the IETF, particularly effective for use with 2.5G
   and 3G wireless networks.

Inamura, et. al.        Expires August 23, 2001                 [Page 3]

Internet-Draft    TCP over 2.5G and 3G Wireless Networks        Feb 2001

2. 2.5G and 3G Link Characteristics

   The link layer characteristics of 2.5G/3G network affects TCP
   performance over the link. The characteristics are layer two ARQ (L2
   ARQ), FEC (forward error correction) and so on [1]. The
   justification for L2 ARQ is discussed in [10], [12].

   For example, W-CDMA (Wideband CDMA) uses RLC (Radio Link Control)
   [3] protocol, that is a kind of Selective Repeat and sliding window
   ARQ. RLC uses protocol data units (PDUs) 336 bits long (including a
   16 bit RLC header). This is the unit for retransmission. The SDU (IP
   packet) is fragmented into PDUs for transmission by RLC.

   There is also FEC and interleaving. In W-CDMA, one to twelve PDUs
   (RLC frames) constitute one FEC frame. The actual size of the FEC
   frame depends on the link conditions and bandwidth allocation. The
   FEC frame is the unit of interleaving.

   RLC uses "status report" type acknowledgments. It does not use
   ack-clocking as in TCP, but rather the poll bit in the header
   explicitly solicits the peer for a status report containing the
   sequence number that the peer acknowledged. The use of the poll bit
   is controlled by timers and by the size of available buffer space in
   RLC. Also, when the peer detects a gap between sequence numbers in
   received frames, it can issue a status report invoke retransmission.

   The maximum number of retransmissions is a configurable RLC
   parameter, with a maximum value of 10. Therefore, RLC can be
   described as an ARQ that can be configured in either
   HIGH-PERSISTENCE or LOW-PERSISTENCE, not PERFECTLY-PERSISTENT,
   according to the terminology in [10].

   In general, the L2 ARQ and FEC can provide an almost error-free
   packet service to the upper layer traffic, i.e. IP. The SDU (IP
   packet) is fragmented into PDUs for transmission. The retransmission
   by L2 ARQ introduces latency and jitter to the SDU flow, that
   results in relatively large BDP (Bandwidth-Delay Product) of the
   2.5G/3G networks.

Inamura, et. al.        Expires August 23, 2001                 [Page 4]

Internet-Draft    TCP over 2.5G and 3G Wireless Networks        Feb 2001

3. TCP over 2.5G and 3G

3.1 Optimization Mechanisms

3.1.1 Large window size

   To utilize link capacity in full, a TCP sender has to send segments
   to "fill the pipe". To achieve the maximum link efficiency for TCP,
   the advertised receive window size needs to be equal to or greater
   than the BDP (Bandwidth Delay Product) of the end-to-end path.

   The wireless link capacity varies by specific technologies used. In
   2.5G/3G wireless, the link BDP tends to large. If the end-to-end
   path contains one or more wireless link, the end-to-end BDP might be
   larger than the default value of receive window size on many TCP
   implementations. The receiver must advertise the appropriate receive
   window size based on the end-to-end BDP.

   The traditional TCP specification limits the window size to 64 KB.
   If the link capacity is expected to be larger than 64 KB, the window
   scale option [6] must be applied. TCP over 2.5G/3G SHOULD support
   appropriate window sizes based on the BDP of the end-to-end path.

   For better round trip time estimates, timestamp option [6] is
   recommended to be implemented when supporting window size of 64 KB
   and more. TCP over 2.5G/3G MAY support timestamp. If the window size
   is larger than or equal to 64KB, implementation SHOULD support
   timestamp option.

3.1.2 Large initial window

   TCP controls its transmit rate using the congestion window
   mechanism. Traditionally, the initial value of the window is one
   segment. Because the delayed Ack mechanism is widely deployed, a TCP
   sender should have an increased initial congestion window of two
   segments[4]. This effectively cancels the delayed Ack by sending two
   segments at once in the very first slow start turn, that contributes
   to avoiding the overhead in connection creation.

   Furthermore, the increased initial window option [5] is also
   effective, especially for small data to be transmitted, which is
   commonly seen in such an application as the Internet-enabled mobile
   wireless devices. For large data transfer, on the other hand, the
   effect of this option is negligible. [7] describes evaluations of
   this option by simulation.

   Two segments of initial congestion window size is recommended in
   [4][5] also notes consideration on use of initial window size of
   more than two. Although the increased initial congestion window is

Inamura, et. al.        Expires August 23, 2001                 [Page 5]

Internet-Draft    TCP over 2.5G and 3G Wireless Networks        Feb 2001

   experimental status, there is no impact of use of it to the majority
   of the Internet if the gateway architecture is deployed that
   terminates TCP connection between the mobile node and the gateway.

   Due to the fact that the delayed Ack mechanism is the standard and
   that the increased initial window option is especially effective for
   the small data transfer that is common for mobile wireless devices,
   TCP over 2.5G/3G MUST use cwnd = 2. It MAY use cwnd > 2 if a gateway
   is present.

3.1.3 MTU larger than default IP MTU

   One of the link layer parameters is MTU (Maximum Transfer Unit). In
   TCP, the slow start mechanism tries to find an adequate rate for the
   link layer. The larger MTU allows TCP to grow the congestion window
   faster [11] , because the window is counted in unit of segments,
   especially when the link condition is good. In contrast, under a
   high BER (Bit Error Rate) situation, smaller MTU is better in terms
   of the chance of successful transmission. With layer two ARQ, the
   upper layer can enjoy larger MTU even in a relatively high BER
   condition. Due to this tradeoff, TCP over 2.5G/3G SHOULD allow
   freedom for designers to choose MTU from a small value (such as
   576B) to a large value (up to 1500B).

3.1.4 Path MTU discovery

   Path MTU discovery allows a sender to determine the maximum
   end-to-end transmission unit for a given routing path. [RFC1191] and
   [RFC1981] describe the MTU discovery procedure for IPv4 and IPv6
   respectively. This allows TCP senders to employ larger segment sizes
   (without causing fragmentation) instead of assuming the default MTU.
   Using larger segment sizes allows for a faster increase in the
   congestion window and a smaller ratio of header overhead to data. It
   should be noted that larger MTUs increase the probability of error
   in a given segment and also increase the packet transmission time.
   TCP over 2.5G/3G implementations SHOULD implement Path MTU
   Discovery. Path MTU Discovery requires intermediate routers to
   support the generation of the necessary ICMP messages. [RFC1435]
   provides recommendations that may be relevant for some router
   implementations.

3.1.5 Selective Acknowledgments

   The selective acknowledgment option (SACK) [8] is effective  when
   multiple TCP segments are lost in a single TCP window [13] . In
   particular, if the link has a large BDP and a certain amount of
   packet loss rate, the ratio of multiple segment losses grows high.
   In such cases, SACK performs better than traditional and Reno TCP
   [9]. TCP over 2.5G/3G MUST support SACK.

Inamura, et. al.        Expires August 23, 2001                 [Page 6]

Internet-Draft    TCP over 2.5G and 3G Wireless Networks        Feb 2001

3.1.6 Explicit Congestion Notification

   Explicit Congestion Notification [RFC2481] allows a TCP receiver to
   inform the sender of congestion in the network by setting the
   ECN-Echo flag; a receiver will set this flag on receiving an IP
   packet marked with the CE bit. The TCP sender can then reduce its
   congestion window. The use of ECN is believed to provide performance
   benefits [RFC2884]. TCP over 2.5G/3G MAY support ECN. [RFC2481] also
   places requirements on intermediate routers (e.g. active queue
   management and setting of the CE bit in the IP header to indicate
   congestion). Thus the use of ECN on the TCP connections is dependent
   on the necessary support from the relevant routers.

3.1.7 Summary

   Items                                  Qualifier                Support
   -------------------------------------------------------------------------
   Large window size                                               SHOULD
   based on BDP
   Window scale option                     Window size>64KB        MUST
   [RFC1323]
   Timestamp option for RTTM               Window size>64KB        SHOULD
   [RFC1323]
   Large initial window (cwnd = 2)                                 MUST
   [RFC2581]
   Large initial window (cwnd > 2)                                 MAY
   [RFC2414]
   Selective Acknowledgment option (SACK)                          MUST
   [RFC2018]
   Path MTU discovery                                              SHOULD
   [RFC1191,RFC1981]
   MTU larger than default IP MTU                                  MAY
   Explicit Congestion Notification(ECN)                           MAY
   [RFC2481]

3.2 Applications

   We introduce wireless services deploying (or capable of deploying)
   the recommendation we discuss here. Net-enabled portable phones and
   wireless ISPs are the two major applications.

3.2.1 i-mode

   Mobile terminal users want to enjoy the Internet experience on their
   handset. This market is emerging and growing rapidly. A deployment
   example is i-mode, a wireless Internet service. As of this writing,
   it is the largest single wireless internet service in the world,
   with 19 million subscribers in Japan.

Inamura, et. al.        Expires August 23, 2001                 [Page 7]

Internet-Draft    TCP over 2.5G and 3G Wireless Networks        Feb 2001

   The next version of i-mode that operates over W-CDMA will be
   launched at the end of May 2001. It will deploy the profiled TCP
   that is described in this document. The browser embedded in the
   handset will utilize the higher speed of 3G infrastructure that can
   provide up to 384kbps packet mode service.

   From the perspective of transport layer, the underlying W-CDMA
   network can be viewed as a network with a relatively large BDP and
   jitter. The loss rate of IP packets is low due to the ARQ, but the
   recovery in the layer two appears as jitter to the higher layers.

   The i-mode infrastructure directly conveys IP packets to the gateway
   for accessing the Internet. In addition to the operation by the
   embedded browser, the i-mode handset can be connected to a computer,
   a PDA and the like as a wireless modem. In this mode, most of data
   communication facilities can be controlled via AT modem commands.
   The W-CDMA infrastructure, whose core network uses GPRS (General
   Packet Radio Service), can be viewed as a large PPP link to GGSN
   (Gateway GPRS Supporting Node). The other side of GGSN is connected
   to fixed networks of ISPs using, for example, leased lines.

3.2.2 WAP

   The WAP Forum [14] is an industry association that has developed
   standards for wireless information and telephony services on digital
   mobile phones and other wireless terminals. In order to address WAP
   functionalities for high speed networks such as 2.5G and 3G networks
   and to aim at convergence to the Internet standards, the WAP Forum
   has been addressing adoption of TCP as its transport protocol,
   benefiting from relevant documents and discussions within IETF and,
   in particular, its PILC working group.

   WAP Forum is about to release a new generation of specifications for
   public review, subject to membership approval. These specifications
   may include the profiled TCP that is described in this submission.
   The WAP forum specification profiling TCP is expected to be
   available for public review in the March 2001 timeframe.

3.2.3 Ricochet MCDN Network

   Ricochet is a wide-area wireless packet data network. The
   architecture for the Ricochet system is the MicroCellular Data
   Network (MCDN). This architecture has seven physical components: 1)
   wireless modems or subscriber devices; 2) a cluster of MicroCells;
   3) Wired Access Points; 4) a nation-wide wired backbone; 5) a Name
   Service; 6) a Network Management System; 7) and gateways. The MCDN
   system architecture is based on a mesh of MicroCells deployed
   throughout a metropolitan area following the part 15.247 FCC rules
   and regulations for the ISM band [1].

Inamura, et. al.        Expires August 23, 2001                 [Page 8]

Internet-Draft    TCP over 2.5G and 3G Wireless Networks        Feb 2001

   After radios have acquired each other, they register with the Name
   Service. The registration process allows the Name Service to store
   the information required to route from the Name Server to the
   registering entity. The Name Server can construct a route between
   the two devices and return an MCDN path with enough information to
   allow packets to be routed between the two entities. Each device
   appends the MCDN path to any packet it wishes to route through the
   network.

   The customer's radio modem typically appears as a standard AT
   command-based modem. The modem sends a LookUp packet to the Name
   Service asking for the MCDN path to the logical name, typically an
   MCDN gateway to the Internet or an intranet. The user's device then
   continues to negotiate a PPP connection so that it can be assigned
   an IP address, an IP router, and a DNS server and become a
   full-fledged communicating member of the global Internet.

   When the user's computing device is attempting to negotiate PPP to
   connect to the network, the radio modem establishes a virtual
   connection, analogous to TCP, to the MCDN gateway, which ensures
   that all of the packets from the user's computing device get routed
   to the Internet via the MCDN gateway. The Wired Access Point places
   the wireless packets onto a high bandwidth wired backbone and route
   them to a central collection point, the Network Interface Facility
   (NIF.) The user's device then appears to the rest of the Internet as
   if it is physically located at the PPP termination point.

Inamura, et. al.        Expires August 23, 2001                 [Page 9]

Internet-Draft    TCP over 2.5G and 3G Wireless Networks        Feb 2001

4. Open Issues

   Other ideas to enhance the performance of TCP over the 2.5G/3G
   networks may include the use of T/TCP, ROHC for TCP, Active Queue
   Management, Eifel Algorithm and so on.

   We have been interested in T/TCP because the Web browsing on a smart
   phone tends to require short TCP connection duration and small
   amount of data transfer. The pattern of such use is more
   transactional rather than streaming. Because T/TCP is regarded as
   being weak for attacks and not widely deployed, we did not recommend
   T/TCP in this document.

   In this document, RFC2414 is treated as an experimental status.
   RFC2414 is now up for reconsideration to become a proposed standard.
   Should it get approved as a proposed standard, we can drop the
   restriction that CWND=3 or 4 may only be used with gateway. There
   are some fairly recent results on using a larger initial cwnd in our
   web server in [15].

Inamura, et. al.        Expires August 23, 2001                [Page 10]

Internet-Draft    TCP over 2.5G and 3G Wireless Networks        Feb 2001

5. Security Considerations

   Please note some of RFCs related to this discussion contains
   consideration to security issues for example [4].

Inamura, et. al.        Expires August 23, 2001                [Page 11]

Internet-Draft    TCP over 2.5G and 3G Wireless Networks        Feb 2001

References

   [1]   Montenegro, G., Dawkins, S., Kojo, M., Magret, V. and N.
         Vaidya, "Long Thin Networks", RFC 2757, January 2000.

   [2]   Third Generation Partnership Project, "3GPP Specifications",
         1999,
         <http://www.3gpp.org/3G_Specs/3G_Specs.htm>.

   [3]   Third Generation Partnership Project, "RLC Protocol
         Specification (3G TS 25.322:)", 1999.

   [4]   Allman, M., Paxson, V. and W. Stevens, "TCP Congestion
         Control", RFC 2581, April 1999.

   [5]   Allman, M., Floyd, S. and C. Partridge, "Increased TCP's
         Initial Window", RFC 2414, September 1998.

   [6]   Jacobson, V., Bdaden, R. and D. Borman, "TCP Extensions for
         High Performance", RFC 1323, May 1992.

   [7]   Allman, M., "An Evaluation of TCP with Larger Initial Windows
         40th IETF Meeting -- TCP Implementations WG. December",
         December 1997.

   [8]   Mathis, M., Mahdavi, J., Floyd, S. and R. Romanow, "TCP
         Selective Acknowledgment Options", RFC 2018, October 1996.

   [9]   Fall, K. and S. Floyd, "Simulation-based Comparisons of Tahoe,
         Reno, and SACK TCP", Computer Communication Review, 26(3) ,
         July 1996.

   [10]  Fairhurst, G. and L. Wood, "Link ARQ issues for IP traffic",
         Internet draft , November 2000,
         <http://www.ietf.org/internet-drafts/draft-ietf-pilc-link-arq-i
         ssues-00.txt>.

   [11]  Dawkins, S. and G. Montenegro, "End-to-end Performance
         Implications of Slow Links", Internet draft , November 2000,
         <http://www.ietf.org/internet-drafts/draft-ietf-pilc-slow-05.tx
         t>.

   [12]  Karn, P., Falk, A., Touch, J., Montpetit, M., Mahdavi, J.,
         Montenegro, G., Grossman, D. and G. Fairhurst, "Advice for
         Internet Subnetwork Designers", Internet draft , November
         2000,
         <http://www.ietf.org/internet-drafts/draft-ietf-pilc-link-desig
         n-04.txt>.

Inamura, et. al.        Expires August 23, 2001                [Page 12]

Internet-Draft    TCP over 2.5G and 3G Wireless Networks        Feb 2001

   [13]  Dawkins, S., Montenegro, G., Magret, V., Vaidya, N. and M.
         Kojo, "End-to-end Performance Implications of Links with
         Errors", Internet draft , November 2000,
         <http://www.ietf.org/internet-drafts/draft-ietf-pilc-error-06.t
         xt>.

   [14]  Wireless Application Protocol, "WAP Specifications", 2000,
         <http://www.wapforum.org>.

   [15]  Allman, M., "A Web Server's View of the Transport Layer", ACM
         Computer Communication Review 30(5), October 2000,
         <http://roland.grc.nasa.gov/~mallman/papers/webobs-ccr.ps>.

Authors' Addresses

   Hiroshi Inamura
   NTT DoCoMo, Inc.
   3-5 Hikarinooka
   Yokosuka Shi, Kanagawa Ken  239-8536
   Japan

   Phone: +81 468 40 3329
   EMail: [email-masked]
   URI:   http://www.nttdocomo.co.jp/

   Gabriel Montenegro
   Sun Microsystems, Inc.

   EMail: [email-masked]

   Max Hata
   NTT DoCoMo, Inc.

   EMail: [email-masked]
   URI:   http://www.nttdocomo.co.jp/

   Masahiro Hara
   Fujitsu, Inc.

   EMail: [email-masked]

Inamura, et. al.        Expires August 23, 2001                [Page 13]

Internet-Draft    TCP over 2.5G and 3G Wireless Networks        Feb 2001

   Joby James
   Motorola, Inc.
   33-A, Ulsoor Road,
   Bangalore  560042
   India

   EMail: [email-masked]

   William Gilliam
   Hewlett-Packard Company
   Cupertino, California

   EMail: [email-masked]

   Alan Hameed
   Fujitsu FNC, Inc.

   EMail: [email-masked]

   Reiner Ludwig
   Ericsson Research
   Ericsson Allee 1
   52134 Herzogenrath
   Germany

   EMail: [email-masked]

   Rodrigo Garces
   Metricom

   EMail: [email-masked]

   Peter Ford
   Microsoft

   EMail: [email-masked]

   Fergus Wills
   Openwave

   EMail: [email-masked]

Inamura, et. al.        Expires August 23, 2001                [Page 14]

Internet-Draft    TCP over 2.5G and 3G Wireless Networks        Feb 2001

Full Copyright Statement

   Copyright (C) The Internet Society (2001). All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph
   are included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC editor function is currently provided by the
   Internet Society.

Inamura, et. al.        Expires August 23, 2001                [Page 15]