Network Working Group H. Inamura (editor)
Internet-Draft NTT DoCoMo, Inc.
Expires: November 15, 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
May 17, 2001
TCP over 2.5G and 3G Wireless Networks
draft-ietf-pilc-2.5g3g-01
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
pilc@grc.nasa.gov.
Distribution of this memo is unlimited.
Inamura, et. al. Expires November 15, 2001 [Page 1]
Internet-Draft TCP over 2.5G and 3G Wireless Networks May 2001
This Internet-Draft will expire on November 15, 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
wireless 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 . . . . . . . . . . . . . . 6
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 . . . . . . . . . . . . . . . . . . . . . 14
A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
Full Copyright Statement . . . . . . . . . . . . . . . . . . 18
Inamura, et. al. Expires November 15, 2001 [Page 2]
Internet-Draft TCP over 2.5G and 3G Wireless Networks May 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 [1].
This document proposes a profile of such techniques, derived from
previous work at the IETF [34], particularly effective for use with
2.5G and 3G wireless networks.
Inamura, et. al. Expires November 15, 2001 [Page 3]
Internet-Draft TCP over 2.5G and 3G Wireless Networks May 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.
RLC preserves order of packet delivery
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 a packet service with a
negligibly small probability of undetected error (failure of the
link CRC), and a low level of loss (non-delivery) for 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 wireless networks.
Inamura, et. al. Expires November 15, 2001 [Page 4]
Internet-Draft TCP over 2.5G and 3G Wireless Networks May 2001
3. TCP over 2.5G and 3G
3.1 Optimization Mechanisms
3.1.1 Large window size
To achieve the maximum performance in 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.
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 the initial phase of the connection.
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
experimental status, there is no impact of use of it to the majority
of the Internet if the split 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,
Inamura, et. al. Expires November 15, 2001 [Page 5]
Internet-Draft TCP over 2.5G and 3G Wireless Networks May 2001
TCP over 2.5G/3G MUST use initial CWND (congestion window) = 2. It
MAY use CWND > 2 if a gateway is present. When applying CWND > 2, it
MAY also be applicable to the restart window.
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. In
the link with error, smaller link PDU size is better in terms of the
chance of successful transmission. With layer two ARQ and
transparent link layer fragmentation, the network layer can enjoy
larger MTU even in a relatively high BER (Bit Error Rate),
condition. Without these features in the link, smaller MTU is
better. 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. [21] and [23]
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. 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. [22] 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 SHOULD support SACK.
3.1.6 Explicit Congestion Notification
Explicit Congestion Notification [25] 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 [24]. TCP over 2.5G/3G MAY support ECN. [25] also places
Inamura, et. al. Expires November 15, 2001 [Page 6]
Internet-Draft TCP over 2.5G and 3G Wireless Networks May 2001
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]
Large initial window (CWND = 2) MUST
[RFC2581]
Large initial window (CWND > 2) MAY
[RFC2414]
Selective Acknowledgment option (SACK) SHOULD
[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 [27], a wireless Internet service. As of this
writing, it is the largest single wireless internet service in the
world, with 23 million subscribers in Japan.
The next version of i-mode that operates over W-CDMA, that is called
FOMA [28], is launched at the end of May 2001. It deploys the
profiled TCP that is described in this document. The browser
embedded in the handset utilizes 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.
Inamura, et. al. Expires November 15, 2001 [Page 7]
Internet-Draft TCP over 2.5G and 3G Wireless Networks May 2001
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 releasing a new generation of specifications. The WAP
specifications include a set of the recommended TCP options that is
described in this submission. The specification of the profiled TCP
is available for public review [20].
3.2.3 Ricochet MCDN Network
Metricom, Inc. is a high-speed wireless data company. Its high-speed
Ricochet mobile access delivers user speeds of 128 kbps, and is
currently available in 15 metropolitan areas and 15 airports in the
United States serving over 50 million potential customers. Ricochet
acts like, feels like, and works like a high-speed wired network
connection. It provides wireless access to information from outside
the confines of an office or any single location.
Ricochet is a wide-area wireless packet data network. The
architecture for the Ricochet system is based on Metricom's Micro
Cellular Data Network (MCDN) technology. 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 MCDN Name Service; 6) a Network Management
System; 7) and MCDN gateways. The MCDN system architecture is based
on a mesh of MicroCells deployed throughout a metropolitan area and
operates in accordance with FCC part 15.247 rules and regulations
for the ISM band [26].
When the user's computing device attempts to negotiate a PPP
connection to the network, the radio modem establishes a virtual
Inamura, et. al. Expires November 15, 2001 [Page 8]
Internet-Draft TCP over 2.5G and 3G Wireless Networks May 2001
connection, analogous to TCP, to the MCDN gateway, which ensures
that all of the packets from the user's computing device are routed
to the Internet. The Wired Access Point provides the actual
connection from the wireless cloud to the wired Ethernet. The data
is place onto a high bandwidth wired backbone and routed 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 November 15, 2001 [Page 9]
Internet-Draft TCP over 2.5G and 3G Wireless Networks May 2001
4. Open Issues
Other ideas to enhance the performance of TCP over the 2.5G/3G
networks may include the ROHC for TCP [18], Active Queue Management
[17] and so on.
We have been interested in T/TCP [16], 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 initial CWND > 2 may only be used with gateway.
There are recent results on the use of a larger initial CWND in
[15].
Eifel algorithm [19] is an enhancement to TCP's error recovery
scheme. It eliminates the retransmission ambiguity, thereby solving
the problems caused by spurious timeouts and spurious fast
retransmits. It is promising for wireless networks where spurious
retransmissions may occur, the algorithm can improve the end-to-end
throughput, because it reduces the penalty of a spurious timeout to
a single (in the common case) spurious retransmission.
DSACK (duplicated SACK) [29] is additional SACK option that notifies
duplicated transmitted segments to TCP sender. This option may
reduce the case of fast retransmit.
Limited Transmit [30] is effective when congestion window size is
small or if a large number of segments in a window are lost. This
may reduce the retransmission of TCP round trip timeout. We need the
evaluation of DSACK and Limited Transmit over the wireless
environment.
Inamura, et. al. Expires November 15, 2001 [Page 10]
Internet-Draft TCP over 2.5G and 3G Wireless Networks May 2001
5. Security Considerations
In 2.5G/3G wireless network, data transmission in ciphertext is
limited only over the air, but cleartext between RAN and core
network. For the end to end security, IP security [33] or TLS [32]
could be deployed. For example, WAP protocol stack is considering to
deploy TLS [31] because of its gateway architecture.
Inamura, et. al. Expires November 15, 2001 [Page 11]
Internet-Draft TCP over 2.5G and 3G Wireless Networks May 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 November 15, 2001 [Page 12]
Internet-Draft TCP over 2.5G and 3G Wireless Networks May 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>.
[16] Braden, R., "T/TCP -- TCP Extensions for Transactions", RFC
1644, July 1994.
[17] Braden, R., Clark, D., Crowcroft, J., Davie, B., Deering, S.,
Estrin, D., Floyd, S., Jacobson, V., Minshall, G., Partridge,
C., Peterson, L., Ramakrishnan, K., Shenker, S., Wroclawski,
J. and L. Zhang, "Recommendations on Queue Management and
Congestion Avoidance in the Internet", RFC 2309, April 1998.
[18] IETF, "Robust Header Compression", 2001,
<http://www.ietf.org/html.charters/rohc-charter.html>.
[19] Ludwig, R. and R. H. Katz, "The Eifel Algorithm: Making TCP
Robust Against Spurious Retransmissions", ACM Computer
Communication Review 30(1), January 2000,
<http://iceberg.cs.berkeley.edu/papers/Ludwig-Eifel-Alg/index.h
tml>.
[20] Wireless Application Protocol, "WAP Wireless Profiled TCP",
WAP-225-TCP-20010331-p, April 2001,
<http://www.wapforum.com/what/review.htm#Proposed>.
[21] Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191,
November 1990.
[22] Knowles, S., "IESG Advice from Experience with Path MTU
Discovery", RFC 1993, March 1993.
[23] McCann, J., Deering, S. and J. Mogul, "Path MTU Discovery for
IP version 6", RFC 1981, August 1996.
[24] Hadi Salim, J. and U. Ahmed, "Performance Evaluation of
Explicit Congestion Notification (ECN) in IP Networks", RFC
2884, july 2000.
[25] Ramakrishnan, K. and S. Floyd, "A Proposal to add Explicit
Inamura, et. al. Expires November 15, 2001 [Page 13]
Internet-Draft TCP over 2.5G and 3G Wireless Networks May 2001
Congestion Notification (ECN) to IP", RFC 2481, January 1999.
[26] FCC Rules and Regulations, "Part 15", October 1997.
[27] NTT DoCoMo, Inc., "i-mode", 2001,
<http://www.nttdocomo.com/i/index.html>.
[28] NTT DoCoMo, Inc., "FOMA", 2001,
<http://foma.nttdocomo.co.jp/english/englishtop.html>.
[29] Floyd, S., Mahdavi, J., Mathis, M. and M. Podolsky, "An
Extension to the Selective Acknowledgement (SACK) Option for
TCP", RFC 2883, July 2000.
[30] Allman, M., Balakrishnan, H. and S. Floyd, "Enhancing TCP's
Loss Recovery Using Limited Transmit", RFC 3042, January 2001.
[31] Wireless Application Protocol, "WAP TLS Profile and
Tunneling", WAP-219-TLS-20010411-p, May 2001,
<http://www.wapforum.com/what/review.htm#Proposed>.
[32] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
2246, January 1999.
[33] Thayer, R., Doraswamy, N. and R. Glenn, "IP Security Document
Roadmap", RFC 2411, November 1998.
[34] Mitzel, D., "Overview of 2000 IAB Wireless Internetworking
Workshop", RFC 3002, December 2000.
Authors' Addresses
Hiroshi Inamura
NTT DoCoMo, Inc.
3-5 Hikarinooka
Yokosuka Shi, Kanagawa Ken 239-8536
Japan
EMail: inamura@mml.yrp.nttdocomo.co.jp
URI: http://www.nttdocomo.co.jp/
Gabriel Montenegro
Sun Microsystems, Inc.
EMail: gab@sun.com
Inamura, et. al. Expires November 15, 2001 [Page 14]
Internet-Draft TCP over 2.5G and 3G Wireless Networks May 2001
Max Hata
NTT DoCoMo, Inc.
EMail: hata@mml.yrp.nttdocomo.co.jp
URI: http://www.nttdocomo.co.jp/
Masahiro Hara
Fujitsu, Inc.
EMail: mhara@FLAB.FUJITSU.CO.JP
Joby James
Motorola, Inc.
33-A, Ulsoor Road,
Bangalore 560042
India
EMail: joby@MIEL.MOT.COM
William Gilliam
Hewlett-Packard Company
Cupertino, California
EMail: wag@cup.hp.com
Alan Hameed
Fujitsu FNC, Inc.
EMail: Alan.Hameed@fnc.fujitsu.com
Reiner Ludwig
Ericsson Research
Ericsson Allee 1
52134 Herzogenrath
Germany
EMail: Reiner.Ludwig@Ericsson.com
Rodrigo Garces
Metricom
EMail: RGarces@Metricom.com
Inamura, et. al. Expires November 15, 2001 [Page 15]
Internet-Draft TCP over 2.5G and 3G Wireless Networks May 2001
Peter Ford
Microsoft
EMail: peterf@Exchange.Microsoft.com
Fergus Wills
Openwave
EMail: fergus.wills@openwave.com
Inamura, et. al. Expires November 15, 2001 [Page 16]
Internet-Draft TCP over 2.5G and 3G Wireless Networks May 2001
Appendix A. Acknowledgements
The authors gratefully acknowledges the valuable advises from
following individuals:
Gorry Fairhurst (gorry@erg.abdn.ac.uk)
Mark Allman (mallman@grc.nasa.gov)
Aaron Folk (aaron@PanAmSat.com)
Inamura, et. al. Expires November 15, 2001 [Page 17]
Internet-Draft TCP over 2.5G and 3G Wireless Networks May 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 November 15, 2001 [Page 18]
