Overview of 2000 IAB Wireless Internetworking Workshop
draft-iab-wirelessws-01
The information below is for an old version of the document that is already published as an RFC.
| Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 3002.
|
|
|---|---|---|---|
| Author | Danny J. Mitzel | ||
| Last updated | 2013-03-02 (Latest revision 2000-08-21) | ||
| RFC stream | Legacy stream | ||
| Intended RFC status | Informational | ||
| Formats | |||
| Stream | Legacy state | (None) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | Became RFC 3002 (Informational) | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-iab-wirelessws-01
Internet Engineering Task Force
Internet Draft D. Mitzel
draft-iab-wirelessws-01.txt Nokia
Expires: February 18, 2000 August 2000
Overview of 2000 IAB Wireless Internetworking Workshop
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.
Abstract
This document provides an overview of a workshop held by the Internet
Architecture Board (IAB) on wireless internetworking. The workshop was
hosted by Nokia in Mountain View, CA, USA on February 29 thru March 2,
2000. The goal of the workshop was to assess current and future uses of
Internet technology in wireless environments, to make recommendations on
research and standardization tasks to improve acceptance of Internet
network and transport protocols in wireless environments, and to evalu-
ate methods to improve communication and collaboration among Internet
standards working groups and those of the telephony and wireless sec-
tors. This report summarizes the conclusions and recommendations of the
IAB on behalf of the IETF community.
Comments should be submitted to the IAB-Wireless-Workshop@ietf.org mail-
ing list.
D. Mitzel [Page 1]
Internet Draft IAB Wireless Workshop August 2000
Table of Contents
1 Introduction . . . . . . . . . . . . . . . . . . . . . . 4
2 Presentation Overview . . . . . . . . . . . . . . . . . . 5
3 Discussion and Observations . . . . . . . . . . . . . . . 10
3.1 Discussion on "Walled Garden" Service Model . . . . . . . 10
3.2 Discussion on Mobility and Roaming . . . . . . . . . . . 11
3.2.1 Discussion on Mobility and Roaming Model . . . . . . . . 11
3.2.2 Discussion on Mobility and Roaming Protocols . . . . . . 12
3.2.3 Discussion on Mobility and Roaming Services . . . . . . . 12
3.3 Discussion on Security Model . . . . . . . . . . . . . . 13
3.3.1 Discussion on User Identity . . . . . . . . . . . . . . . 13
3.3.2 Discussion on WAP Security . . . . . . . . . . . . . . . 14
3.3.3 Discussion on 3G Network Security . . . . . . . . . . . . 14
3.4 Discussion on Transports . . . . . . . . . . . . . . . . 15
3.4.1 Discussion on Link Characteristics and Mobility
Effect on Transport . . . . . . . . . . . . . . . . . . . . . . . . 15
3.4.2 Discussion on WAP Transport . . . . . . . . . . . . . . . 16
3.4.3 Discussion on IETF Transport Activities . . . . . . . . . 17
3.5 Discussion on Aeronautical Telecommunication Network
(ATN) Routing Policy . . . . . . . . . . . . . . . . . . . . . . . . 18
3.6 Discussion on QoS Services . . . . . . . . . . . . . . . 19
3.6.1 Discussion on "Last Leg" QoS . . . . . . . . . . . . . . 19
3.6.2 Discussion on Path QoS Discovery . . . . . . . . . . . . 19
3.7 Discussion on Header Compression . . . . . . . . . . . . 20
3.8 Discussion on Applications Protocols . . . . . . . . . . 21
3.9 Discussion on Proxy Agents . . . . . . . . . . . . . . . 22
3.10 Discussion on Adoption of IPv6 . . . . . . . . . . . . . 22
3.11 Discussion on Signaling . . . . . . . . . . . . . . . . . 23
3.12 Discussion on Interactions Between IETF and Other
Standards Organizations . . . . . . . . . . . . . . . . . . . . . . 24
4 Recommendations . . . . . . . . . . . . . . . . . . . . . 25
4.1 Recommendations on Fostering Interaction with Non-
Internet Standards Organizations . . . . . . . . . . . . . . . . . . 25
4.1.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.1.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.1.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.2 Recommendations for Dealing with "Walled Garden"
Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.2.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.2.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.3 Recommendations on IPv4 and IPv6 Scaling . . . . . . . . 27
4.3.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.3.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.3.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.3.4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.4 Recommendations on IPv4 and IPv6 Mobility . . . . . . . . 28
D. Mitzel [Page 2]
Internet Draft IAB Wireless Workshop August 2000
4.4.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.4.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.4.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.5 Recommendations on TCP and Transport Protocols . . . . . 29
4.5.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.5.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.5.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.5.4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.5.5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.5.6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.6 Recommendations on Routing . . . . . . . . . . . . . . . 31
4.6.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.6.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.7 Recommendations on Mobile Host QoS Support . . . . . . . 32
4.7.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.7.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.8 Recommendations on Application Mobility . . . . . . . . . 32
4.9 Recommendations on TCP/IP Performance Characteriza-
tion in WAP-like Environment . . . . . . . . . . . . . . . . . . . . 32
4.10 Recommendations on Protocol Encoding . . . . . . . . . . 33
4.11 Recommendations on Inter-Domain AAA Services . . . . . . 33
4.12 Recommendations on Bluetooth . . . . . . . . . . . . . . 33
4.13 Recommendations on Proxy Architecture . . . . . . . . . . 34
4.14 Recommendations on Justifying IPv6-based Solutions
for Mobile / Wireless Internet . . . . . . . . . . . . . . . . . . . 34
5 Security Considerations . . . . . . . . . . . . . . . . . 34
6 Acknowledgments . . . . . . . . . . . . . . . . . . . . . 35
7 Bibliography . . . . . . . . . . . . . . . . . . . . . . 35
A Participants . . . . . . . . . . . . . . . . . . . . . . 39
B Author's Address . . . . . . . . . . . . . . . . . . . . 40
C Changes from draft-iab-wirelessws-00.txt . . . . . . . . 40
D. Mitzel [Page 3]
Internet Draft IAB Wireless Workshop August 2000
1 Introduction
Wireless technology, including wireless LANs, data transfer over cellu-
lar radio (GSM, 3GPP, etc), and mobile operations from aircraft and near
earth spacecraft are becoming increasingly important. Some market pro-
jections suggest that a mobile Internet in parallel with or augmenting
the wired Internet may be comparable in size to the wired Internet as
early as 2003.
The wireless operators have not, however, chosen to use IPv4, TCP, full
HTTP/HTML, and other applications for a variety of reasons. These relate
to edge device cost, bandwidth limitations, perceived protocol imperfec-
tions, unnecessary complexities, the chattiness of the application pro-
tocols, and network layer addressing issues. Unfortunately, this creates
some serious issues at the wired/wireless demarcation: end to end opera-
tion is sacrificed, security is compromised, and automated content modi-
fication in some form becomes necessary. The IAB considers these to be
serious fundamental issues, which will in time be a serious impediment
to the usability of the combined Internet if not addressed.
The Internet Architecture Board (IAB), on February 29 thru March 2,
2000, held an invitational workshop on wireless internetworking. The
goal of the workshop was to assess current and future uses of Internet
technology in wireless environments, to make recommendations on research
and standardization tasks to improve acceptance of Internet network and
transport protocols in wireless environments, and to evaluate methods to
improve communication and collaboration among Internet standards working
groups and those of the telephony and wireless sectors.
The following topics were defined for discussion:
+ Local area wireless technologies
+ Cellular wireless technologies
+ Wireless Application Protocol (WAP)
+ Near-space and aviation wireless applications
+ Voice over IP (VoIP) over wireless networks
+ Security over wireless networks
+ Transport and QoS over wireless networks
+ Use of WWW protocols over wireless and small screen devices
D. Mitzel [Page 4]
Internet Draft IAB Wireless Workshop August 2000
+ Addressing requirements for wireless devices
+ Compression and bit error requirements for wireless networks
The fundamental question addressed in these discussion is "what are the
issues, and what really needs to be done to unify the Internet below the
application layer." Applications will also need to be addressed, but
were perceived to be more than could be usefully discussed in a three-
day workshop, and probably require different expertise.
Section 2 presents a concise overview of the individual presentations
made during the workshop. References to more extensive materials are
provided. Details on major discussion topics are provided in section 3.
Section 4 presents the recommendations made to wireless operators, IRTF,
and IETF on the architectural roadmap for the next few years. It should
be noted that not all participants agreed with all of the statements,
and it was not clear whether anyone agreed with all of them. However,
the recommendations made are based on strong consensus among the partic-
ipants. Finally, section 5 highlights references to security considera-
tions discussed, appendix A lists contact information of workshop par-
ticipants, and appendix B lists the author contact information.
2 Presentation Overview
Title: Overview of Wireless IP Devices (Network Implications...)
Presenter: Heikki Hammainen
Reference:
http://www.iab.org/IAB-wireless-workshop/talks/hh-IABpub.PDF,
http://www.iab.org/IAB-wireless-workshop/talks/hh-IABpub.ppt
Overview:
Title: Overview of IEEE 802.11 Wireless LAN's & Issues Running IP
over IEEE 802.11?
Presenter: Juha Ala-Laurila
Reference:
http://www.iab.org/IAB-wireless-work-
shop/talks/IEEE80211_IP.ppt
Overview:
Title: Overview of Bluetooth Wireless & Issues Running IP over
Bluetooth?
D. Mitzel [Page 5]
Internet Draft IAB Wireless Workshop August 2000
Presenter: Pravin Bhagwat
Reference:
http://www.iab.org/IAB-wireless-workshop/talks/BT-
overview.PDF,
http://www.iab.org/IAB-wireless-workshop/talks/BT-overview.ppt
Overview:
Title: Overview of Cellular Data Systems & Approaches to more IP
centric Cellular Data System
Presenter: Jonne Soinien
Reference:
http://www.iab.org/IAB-wireless-workshop/talks/Cellu-
lar_JSo.PDF,
http://www.iab.org/IAB-wireless-workshop/talks/Cellu-
lar_JSo.ppt
Overview:
Title: IP Packet Data Service over IS-95 CDMA
Presenter: Phil Karn
Reference:
http://www.iab.org/IAB-wireless-workshop/talks/karn/index.htm
Overview:
Title: Wireless Internet Networking
Presenter: Chih-Lin I
Reference:
http://www.iab.org/IAB-wireless-workshop/talks/IAB000229.PDF,
http://www.iab.org/IAB-wireless-workshop/talks/IAB000229.ppt
Overview:
Title: Mobile IP in Cellular Data Systems
Presenter: Charlie Perkins
Reference:
http://www.iab.org/IAB-wireless-workshop/talks/WLIP99.PDF,
http://www.iab.org/IAB-wireless-workshop/talks/WLIP99.ppt
D. Mitzel [Page 6]
Internet Draft IAB Wireless Workshop August 2000
Overview:
Title: Overview of WAP
Presenter: Alastair Angwin
Reference:
http://www.iab.org/IAB-wireless-workshop/talks/iab-wap-1.pdf
Overview:
Title: Mobile Wireless Internet Forum (MWIF)
Presenter: Alastair Angwin
Reference:
http://www.iab.org/IAB-wireless-workshop/talks/MWIF_TC_Presen-
tation.PDF,
http://www.iab.org/IAB-wireless-workshop/talks/MWIF_TC_Presen-
tation.ppt
Overview:
Title: Some WAP History
Presenter: Jerry Lahti
Reference:
http://www.iab.org/IAB-wireless-workshop/talks/waphist.PDF,
http://www.iab.org/IAB-wireless-workshop/talks/waphist.ppt
Overview:
Title: Near-space Wireless Applications
Presenter: Mark Allman
Reference:
http://www.iab.org/IAB-wireless-workshop/talks/allman-iab-
wireless.pdf,
http://www.iab.org/IAB-wireless-workshop/talks/allman-iab-
wireless.ps
Overview:
Title: Air Traffic / Aviation Wireless
D. Mitzel [Page 7]
Internet Draft IAB Wireless Workshop August 2000
Presenter: Chris Wargo
Reference:
http://www.iab.org/IAB-wireless-workshop/talks/wargo-talk.PDF,
http://www.iab.org/IAB-wireless-workshop/talks/wargo-talk.ppt
Overview:
Title: VoIP over Wireless
Presenter: Christian Huitema
Reference:
http://www.iab.org/IAB-wireless-workshop/talks/iab-wless-
voip.PDF,
http://www.iab.org/IAB-wireless-workshop/talks/iab-wless-
voip.ppt
Overview:
Title: Security Issues in Wireless Networks and Mobile Computing
Presenter: N. Asokan
Reference:
http://www.iab.org/IAB-wireless-workshop/talks/mobile-secu-
rity.PDF,
http://www.iab.org/IAB-wireless-workshop/talks/mobile-secu-
rity.ppt
Overview:
Title: Security for Mobile IP in 3G Networks
Presenter: Pat Calhoun
Reference:
http://www.iab.org/IAB-wireless-workshop/talks/mip-sec-3g.PDF,
http://www.iab.org/IAB-wireless-workshop/talks/mip-sec-3g.ppt
Overview:
Title: On Inter-layer Assumptions (A View from the Transport Area)
Presenter: Mark Handley
Reference:
http://www.iab.org/IAB-wireless-workshop/talks/handley-
D. Mitzel [Page 8]
Internet Draft IAB Wireless Workshop August 2000
wireless.pdf,
http://www.iab.org/IAB-wireless-workshop/talks/handley-wire-
less.ps
Overview:
Title: Does current Internet Transport work over Wireless?
Presenter: Sally Floyd
Reference:
http://www.iab.org/IAB-wireless-workshop/talks/IAB-wireless-
Mar00.pdf,
http://www.iab.org/IAB-wireless-workshop/talks/IAB-wireless-
Mar00.ps
Overview:
Title: QOS for Wireless (DiffServ, IntServ, other?)
Presenter: Lixia Zhang
Reference:
http://www.iab.org/IAB-wireless-workshop/talks/zhang-feb-
IAB.PDF,
http://www.iab.org/IAB-wireless-workshop/talks/zhang-feb-
IAB.ppt
Overview:
Title: Do current WWW Protocols work over Wireless and Small Screen
Devices?
Presenter: Gabriel Montenegro
Reference:
http://www.iab.org/IAB-wireless-workshop/talks/wireless-
www.PDF,
http://www.iab.org/IAB-wireless-workshop/talks/wireless-
www.ppt
Overview:
Title: Compression & Bit Error Requirements for Wireless
Presenter: Mikael Degermark
D. Mitzel [Page 9]
Internet Draft IAB Wireless Workshop August 2000
Reference:
http://www.iab.org/IAB-wireless-workshop/talks/iab-hc.PDF,
http://www.iab.org/IAB-wireless-workshop/talks/iab-hc.ppt
Overview:
Title: Addressing Requirements for Wireless Devices & IPv6
Presenter: Bob Hinden
Reference:
http://www.iab.org/IAB-wireless-workshop/talks/Addressing-
IPv6.PDF,
http://www.iab.org/IAB-wireless-workshop/talks/Addressing-
IPv6.ppt
Overview:
3 Discussion and Observations
During the workshop presentations a number of issues were discussed and
observations made. The following sections 3.1 -- 3.12 summarize these
discussion and observations. Rather than organizing the material lin-
early by presentation, it is grouped according to common "themes" and
issues.
3.1 Discussion on "Walled Garden" Service Model
Presentations from members involved in the cellular wireless (3GPP,
3G.IP, MWIF) and WAP environments quickly illustrated a significant dif-
ference in protocol specification and service models from that typically
assumed by the Internet community. These communities focus on defining a
profile (set of protocols and operational parameters) that combine to
provide a well defined user service. In addition, the carriers typically
prefer to have complete (or as much as possible) control over the entire
service, including user access device, transmission facilities, and ser-
vice "content". This style of service model appears to have been inher-
ited from the classic telephony provider model. The term "walled garden"
was coined to describe the resulting captive customer economic and ser-
vice model. That is, the user is constrained within the limits of the
service provided by the carrier with limited ability to extend features
or access services outside the provider.
The "walled garden" service model is in stark contrast to the "open"
service assumed in the Internet. The application, access device, and
service content may each be controlled by a different entity, and the
service provider is typically viewed as little more than a "bit pipe".
Additionally, specification typically define a standalone protocol or
D. Mitzel [Page 10]
Internet Draft IAB Wireless Workshop August 2000
application rather than the set of features and interoperation with
other components required to deploy a commercial service.
Some discussion focused on whether cellular carriers could be persuaded
to transition toward the Internet "open" service model. Responses indi-
cated that there was little hope of this as carriers will always fight
being reduced to a "bit pipe", fearing they cannot sustain sufficient
revenues without the value added services. An additional point raised
was that the closed model of the "walled garden" simplifies a number of
issues, such as security, authorization, and billing when the entire
network is considered secured and controlled under a single administra-
tion. These simplification can eliminate roadblocks to service deploy-
ment before scalable, interdomain solutions are available.
Even though there seems little hope of evolving carriers away from the
"walled garden" service in the short term, there was significant value
in recognizing its presence. This led to observations that "walled gar-
den" Internet-based services will operate somewhat like current intranet
services. Also, mechanisms should be investigated to simplify interoper-
ation and controlled access to the Internet. Finally, the difference
between Internet protocol specification contrasted to service profiles
highlights some of the confusion those in the telephony environment
encounter when attempting to incorporate Internet capabilities.
Much of the current work in extending Internet-based services to cellu-
lar customers has focused on data services such as email or web access.
One observation on the reluctance of carriers to release any control
over services was that this may be an impediment to adoption of Inter-
net-based voice services. Current work on voice over IP (VoIP) and call
signaling (SIP [30]) loosens control over these services, much of the
functionality is moved into the SIP agent with the carrier being reduced
to an access provider (i.e., "bit pipe").
3.2 Discussion on Mobility and Roaming
An inherent characteristic of wireless systems is their potential for
accommodating device roaming and mobility. Some discussion focused on
the model of mobility presented to the user. There was also considerable
interest and discussion on protocols employed, using cellular telephony
and/or IP-based solutions. Finally, there was some interest in exploring
new services enabled by mobility.
3.2.1 Discussion on Mobility and Roaming Model
There was considerable discussion and concern over what style of mobil-
ity and roaming needs to be supported. Current usage in the Internet is
dominated by the mode where a user performs some actions at one loca-
tion, then shuts down and moves, followed by restart at a new location.
D. Mitzel [Page 11]
Internet Draft IAB Wireless Workshop August 2000
3G.IP uses the term "macro mobility" to describe this mode.
The discussion attempted to discern whether the current mode of usage is
a perceived limitation introduced by current protocols. A clear consen-
sus could not be achieved. There was agreement that introduction of this
"macro mobility" roaming is a worthwhile first step. However, that was
immediately followed by questions on whether it is a sufficient first
step, and warning not to stop at this level. There seems significant
issues for continued investigation related to enabling continual usage
of a device during roaming ("micro mobility") and the ability to
retrieve previous connections after a roaming event.
3.2.2 Discussion on Mobility and Roaming Protocols
Selection between cellular and IP protocols in support of roaming pro-
vided another topic for significant discussion. Cellular operators have
already deployed protocols providing significant support for roaming.
This has led several efforts, such as 3GPP and 3G.IP, toward architec-
ture relying on telephone system for all mobility support, hiding roam-
ing from the IP layer.
Arguments for cellular-based roaming centered on concerns about the
mobile IP model. There was concern that home agent and foreign agent
involvement in delivery might introduce bottleneck, and the perception
that mobile IP handoff is too slow. A rebuttal offered was that IETF
mobileip working group is introducing hierarchy and route optimization
to improve performance and robustness [50], and there was disagreement
on the point regarding slow handoff under mobile IP.
Detriments to the cellular-based roaming include the lack of IP support
out to the mobile device and the added tunneling protocols and overhead
required. Additionally, roaming is less well defined when traversing
service provider boundaries and may involve highly non-optimal forward-
ing path. There appears significant work remaining to reach convergence
on opinions, and additional investigation to support roaming across cel-
lular, WLAN, and IP boundaries.
3.2.3 Discussion on Mobility and Roaming Services
3G.IP mobility model is primarily focused on providing ubiquitous ser-
vice across a range of access media. However, the presentation also
highlighted a desire to develop new "location based" services. Examples
presented include locating nearby services or receiving advertisement
and solicitations from nearby business.
There are several Internet protocols defined, such as anycast service
[47] and SLP [28], that may aid in developing location based services.
However, there was considerable frustration on the part of 3G.IP in that
D. Mitzel [Page 12]
Internet Draft IAB Wireless Workshop August 2000
there appears little commercial support of these protocols, and even
less direction on how to assemble and coordinate the required protocols
to deploy the desired services.
This exchange illustrated the disconnect between interpreting Internet
standards and telephony service profiles. First, in the Internet many
protocols are defined but many are optional. Protocol support is typi-
cally driven by market demand, which can lead to "chicken and egg" prob-
lem. Secondly, individual protocols and applications are developed
rather than complete profile to compose a commercial service. For this
service, evaluating the usage and scalability of service discovery pro-
tocols appears to be an area open for further investigation.
3.3 Discussion on Security Model
Mobility and wireless environments introduce many complexities and
potential attacks to user authentication and privacy. In addition to the
discussion presented below, there was an overriding statement made
regarding the methodology that must be followed for all security proto-
col development. It was felt quite strongly that the only chance for
success is that the definition be done in a public forum, allowing full
disclosure of all algorithms and thorough review by security experts.
Stated an alternate way, defining protocols in a closed forum relying on
cellphone manufacturers, or other non-experts on IP security, is very
likely to create security exposures.
3.3.1 Discussion on User Identity
Storage of user identity can have significant effect on device usage and
device portability. Discussion focused on whether identity should be
tied to the mobile device or a transferable SIM card. Fixing identifica-
tion with the device may simplify manufacture and provide some tamper
resistance, however it makes it very difficult to deploy a public device
taking on the identity of the user. These alternative also affect trans-
fer of identity and configuration state on device replacement or
upgrade.
A related topic revolves around the user desire to employ a single
device but to take on a different identity and privilege based on the
usage at hand (e.g., to gain corporate access, home access, or Internet
access). The ability and ease of assuming these multiple identities may
be highly dependent on the model of identity integration, as discussed
above. Discussion highlighted potential pitfalls based on tieing of
device and user identities. IPsec use of device IP address inhibits
roaming capabilities as the address may change based on location, and
precludes distinguishing identity and capabilities for current usage.
IPsec requires additional work to accommodate this added flexibility.
D. Mitzel [Page 13]
Internet Draft IAB Wireless Workshop August 2000
A final topic of discussion on user identity establishment was whether
possession of the device is sufficient, or whether the user should be
required to authenticate to the device. In the real world the first
alternative is exemplified by the credit card model, while the second is
more analogous to the ATM card where the user must also provide a PIN
code. Both models seem useful in the real world, and it's likely both
will have uses in wireless networking.
3.3.2 Discussion on WAP Security
WAP wireless transport security (WTLS) is based on TLS [20], with opti-
mized handshake to allow frequent key exchange. The security service
employs a "vertical" integration model, with protocol components
throughout the network stack. Some argued that this is the wrong model.
A better approach may have been a security layer with well defined
interfaces. This could allow for later tradeoffs among different proto-
cols, driven by market, applications, and device capabilities.
Additional statements argued that the WAP security model illustrates
dangers from optimizing for a limited usage domain ("walled garden").
Content provider systems requiring security (e.g., banks) must deploy a
special WAP proxy, which breaks the model of a single WAP "domain". Sim-
ilar issues are inherent in gatewaying to the Internet.
3.3.3 Discussion on 3G Network Security
The existing GSM/GPRS model uses long term shared secrets (embedded in
SIM card) with one-way authentication to the network, and with privacy
only provided on the access link. This is an example where the "walled
garden" service model has an advantage. Complete control over the ser-
vice access devices and network greatly reduces the range of security
concerns and potential attacks.
Future 3GPP and 3GPP2 plan to push IP all the way out to the wireless
device. An observation is that this results in more potential for expo-
sure of signaling and control plane to attacks. Desire is to perform
mutual authentication and securing of the network. This is a difficult
problem with additional issues remaining to be solved; however the
statement was made that relying on IP and open standards is more likely
to produce a provably secure network than former reliance on SS7 proto-
cols and obscurity.
Completing support for the security requirements of the 3GPP/3GPP2 net-
work seems to require resolving issues in two primary areas, AAA ser-
vices and mobile IP. AAA is required for authentication, authorization,
and billing. Remaining issues center around cross domain AAA, authenti-
cation using PKI, and there was considerable aversion to use of IPsec
and IKE protocols due to perceived overhead and delay. Mobile IP issues
D. Mitzel [Page 14]
Internet Draft IAB Wireless Workshop August 2000
revolve around solutions to reduce the security associations required
between mobile node and home agent, mobile node and foreign agent, and
the home and foreign agent. An interim solution being investigated
involves use of a RADIUS server [56]; however, there are concerns with
repeated dynamic key generation on each handoff or hiding some details
of handoffs, which may violate assumptions in mobile IP protocol [48].
Evaluating requirements and addressing all of these open issues appears
to be an excellent opportunity for mutual cooperation on open standard-
ization and review.
3.4 Discussion on Transports
Discussion on transport protocols touched on a broad range of issues.
Concerns ranged from the effects of wireless link characteristics and
mobility effect on TCP, to development of new transport protocols such
as WAP Wireless Transaction Protocol (WTP). In addition, a significant
amount of time was spent reviewing ongoing efforts within the IETF on
TCP transport enhancements and investigation of new transports.
3.4.1 Discussion on Link Characteristics and Mobility Effect on Trans-
port
TCP makes assumptions on loss as congestion indication. The statement
was made that TCP was designed for links with about 1% corruption loss,
and provided that constraint is met then TCP should function properly.
Presentation on IS-95 CDMA-based data service showed that it conditions
line to provide 1--2% error rate with little correlation between loss.
Similar conditioning and Forward Error Correction (FEC) mechanisms may
be appropriate for other wireless and satellite systems [4]. This may
not be true for all wireless media, but it was interesting in the fact
that it indicates TCP should work properly on many wireless media. How-
ever, the amount of discussion and suggestions on TCP performance opti-
mizations showed that there can be a considerable gap between merely
working and working well.
One issue raised several times was related to the effects of non-conges-
tive loss on TCP performance. In the wireless environment non-congestive
loss may be more prevalent due to corruption loss (especially if the
wireless link cannot be conditioned to properly control error rate) or
an effect of mobility (e.g., temporary outage while roaming through an
area of poor coverage). These losses can have great detrimental effect
on TCP performance, reducing the transmission window and halving the
congestion window size. Much of the discussion focused on proposing
mechanisms to explicitly indicate a non-congestive loss to the TCP
source. Suggestions included a Non-Congestive Loss Indication (NCLI)
sent for instance when packet corruption loss is detected, or sending a
Source Encourage (SE) to stimulate source transmission at the end of an
outage. In addition to data corruption, wireless links can also
D. Mitzel [Page 15]
Internet Draft IAB Wireless Workshop August 2000
experience dropouts. In this situation any active TCP sessions will com-
mence periodic retransmissions, using an exponentially increasing back-
off timer between each attempt. When the link becomes available it may
be many seconds before the TCP sessions resume transmission. Mechanisms
to alleviate this problem, including packet caching and triggered
retransmission were discussed. The more generic form of all of these
mechanisms is one that allows the state of the layer two (datalink) sys-
tem to signal to the TCP session its current operating mode. Developing
a robust form of such a signaling mechanism, and integrating these sig-
nals into the end-to-end TCP control loop may present opportunities to
improve TCP transport efficiency for wireless environments.
TCP improvements have been incorporated to support "long" links (i.e.,
those with large delay and bandwidth characteristics) [36], however con-
siderable expertise may still be required to tune socket buffers for
maximum performance. Some work has been done on auto-tuning buffers,
which shows promise [58]. An additional problem with large windows and
auto-tuning is the added header overheads. This may exasperate the prob-
lems of running TCP over low bandwidth links. Suggestions included to
explore dynamic negotiation of large window extensions in the middle of
a connection to alleviate these issues. A final issue raised with regard
to large window extensions is the corresponding large bursts and their
effect on congestion. There has been some investigation into pacing TCP
segment transmissions [41], however there is disagreement on the effec-
tiveness of this proposal [2].
There was also concern regarding mobility effects on TCP performance.
TCP has implicit assumptions on bounding propagation delay. If delay
exceeds the smoothed round trip time plus four times the round trip
variance then the segment is considered lost, triggering the normal
backoff procedures. Could these assumptions be violated by variable
delays in a mobile environment? TCP also has arbitrary assumption that
three duplicate ACKs signal loss. Could this be violated by segment loss
or duplication during handoff? Work on D-SACK [25] may alleviate these
worries, detecting reordering and allowing for adaptive DUP-ACK thresh-
old. Finally, there was suggestion it might be appropriate to adapt
(e.g., trigger slow start) immediately after mobile handoff on the
assumption that path characteristics may differ.
3.4.2 Discussion on WAP Transport
WAPF considered TCP connection setup and teardown too expensive in terms
of bit overhead and latency when required for every transaction. WAPF
developed the Wireless Transaction Protocol (WTP), with some inspiration
from T/TCP [12]. WTP offers several classes of service ranging from
unconfirmed request to single request with single reply transaction.
Data is carried in the first packet and 3-way handshake eliminated to
reduce latencies. In addition acknowledgments, retransmission, and flow
D. Mitzel [Page 16]
Internet Draft IAB Wireless Workshop August 2000
control are provided.
Discussion on WTP centered on assessing details on its operation.
Although it incorporates mechanisms for reliability and flow control
there was concern that it may miss critical or subtle transport issues
learned through years of Internet research and deployment experience.
One potential area for disaster appeared to be the use of fixed retrans-
mission timers and lack of congestion control. This gave rise to sugges-
tions that the IETF write up more details on the history and tradeoffs
in transport design to aid others doing transport design work, and sec-
ondly that the IETF advocate that congestion control is not optional
when using rate adaptive transport protocols.
The remaining discussion on WAP transport primarily focused on ways to
share information. It was suggested that any results from WAPF study of
TCP shortcomings that led to its rejection might be useful for IETF
review as inputs for TCP modifications. Similar comments were raised on
study of T/TCP shortcomings and its potential exposure to Denial of Ser-
vice (DoS) attacks. It was also encouraged that WAPF members participate
in the IETF to directly contribute requirements and remain abreast of
current efforts on evolving TCP operation and introduction of new trans-
port (see discussion below in section 3.4.3).
3.4.3 Discussion on IETF Transport Activities
Discussion on transport work in the IETF presented a large array of
activities. Recent work on transport improvement includes path MTU, For-
ward Error Correction (FEC), large windows, SACK, NewReno Fast Recovery,
ACK congestion control, segment byte counting, Explicit Congestion Noti-
fication (ECN), larger initial transmit windows, and sharing of related
TCP connection state [3,4,5,6,24,25,43,53,63]. Work on new transports
includes SCTP [61] in the IETF Signaling Transport (sigtran) working
group and TCP-Friendly Rate Control (TFRC) [1] by researchers at ACIRI.
SCTP provides a reliable UDP-like protocol supporting persistent associ-
ations and in-order delivery with congestion control. TFRC is targeted
at unreliable, unicast streaming media. Finally, work in the IETF End-
point Congestion Management (ecm) working group is looking at standard-
izing congestion control algorithms, and work in the Performance Impli-
cations of Link Characteristics (pilc) working group is characterizing
performance impacts of various link technologies and investigating per-
formance improvements.
This vast array of ongoing research and standards development seemed a
bit overwhelming, and there was considerable disagreement on the perfor-
mance and applicability of several TCP extensions. However, this discus-
sion did raise a couple of key points. First, transport work within the
Internet community is not stagnant, there is a significant amount of
interest and activity in improvement to existing protocols and
D. Mitzel [Page 17]
Internet Draft IAB Wireless Workshop August 2000
exploration of new protocols. Secondly, the work with researchers in
satellite networking has demonstrated the tremendous success possible in
close collaboration. The satellite networking community was dissatisfied
with initial TCP performance on long delay links. Through submission of
requirements and collaborative investigation a broad range of improve-
ments have been proposed and standardized to address unique characteris-
tics of this environment. This should hopefully set a very positive
precedent to encourage those in the wireless sector to pursue similar
collaboration in adoption of Internet protocols to their environment.
3.5 Discussion on Aeronautical Telecommunication Network (ATN) Routing
Policy
The Aeronautical Telecommunication Network (ATN) has goals to improve
and standardize communications in the aviation industry. This ranges
across air traffic management and control, navigation and surveillance,
all the way up to passenger telephone service and entertainment. This
also involves integration of both fixed ground segments and mobile air-
craft. Supporting the ATN architecture using Internet protocols may
introduce additional requirements on the routing infrastructure.
Current ATN views each aircraft as an autonomous network (AS) with
changing point of attachment as it "roams" through different airspace.
Addressing information associated with the aircraft is fixed, which
makes route aggregation difficult since they're not related to topology,
and also increases the frequency of updates. Additionally, the aircraft
may be multiply attached (within coverage of multiple ground and space-
based access networks), requiring routing policy support for path selec-
tion. Finally, QoS path selection capabilities may be beneficial to
arbitrate shared access or partition real-time control traffic from
other data traffic.
Initial prototype of ATN capabilities have been based on ISO IDRP [33]
path selection and QoS routing policy. There was some discussion whether
IDRP could be adopted for use in an IP environment. There was quick
agreement that the preferred solution within the IETF would be to
advance BGP4++ [8,54] as an IDRP-like replacement. This transitioned
discussion to evaluation of ATN use of IDRP features and their equiva-
lent to support in BGP. Several issues with BGP were raised for further
investigation. For example, whether BGP AS space is sufficient to accom-
modate each aircraft as an AS? Also issues with mobility support; can
BGP provide for dynamically changing peering as point of attachment
changes, and alternative path selection policies based on current peer-
ings? A significant amount of additional investigation is required to
fully assess ATN usage of IDRP features, especially in the QoS area.
These could lead to additional BGP requirements, for instance to effect
different prioritization or path selection for aircraft control vs. pas-
senger entertainment traffic.
D. Mitzel [Page 18]
Internet Draft IAB Wireless Workshop August 2000
3.6 Discussion on QoS Services
Enabling support for voice and other realtime services along with data
capabilities requires Quality of Service (QoS) features to arbitrate
access to the limited transmission resources in wireless environment.
The wireless and mobile environment requires QoS support for the last
leg between the mobile device and network access point, accommodating
roaming and unique characteristics of the wireless link.
In addition to the discussion presented below, it was felt quite
strongly that it is critical any QoS facility be provided as an underly-
ing service independent of payload type. That is, there should be no
built in knowledge of voice or other application semantics. This
results in a feature that can be leveraged and easily extended to sup-
port new applications.
3.6.1 Discussion on "Last Leg" QoS
Discussion on voice over IP (VoIP) emphasized that (wireless) access
link is typically the most constrained resource, and while contention
access (CSMA) provides good utilization for data it is not ideal for
voice. Two models were identified as potential solution in VoIP archi-
tecture. The first is to have the wireless device directly signal the
local access router. A second alternative is to have the call control
element (SIP agent [30]) "program" the edge router. This tradeoff seemed
to be an area open for additional investigation, especially given the
complications that may be introduced in the face of mobility and roaming
handoffs. This appears a key component to solve for success in VoIP
adoption.
Work within the IEEE 802.11 WLAN group identified similar requirements
for QoS support. That group is investigating a model employing two
transmission queues, one for realtime and one for best-effort traffic.
Additional plans include mapping between IP DiffServ markings [14,46]
and IEEE 802 priorities.
The statement was also made that QoS over the wireless link is not the
fundamental problem, rather it is handling mobility aspects and seemless
adaptation across handoffs without service disruption. There were con-
cerns about mechanisms establishing per-flow state (RSVP [13]). Issues
include scaling of state, and signaling overhead and setup delays on
roaming events. DiffServ [9] approach allows allocating QoS for aggre-
gate traffic class, which simplifies roaming. However, DiffServ requires
measurement and allocation adjustment over time, and policing to limit
amount of QoS traffic injected.
3.6.2 Discussion on Path QoS Discovery
D. Mitzel [Page 19]
Internet Draft IAB Wireless Workshop August 2000
The HDR high speed wireless packet data system under development at
Qualcomm highlights unique characteristics of some wireless media. This
system provides users a channel rate between 38.4Kb/s and 2.4Mb/s, with
throughput dependent on channel loading and distance from network access
point. This gave rise to considerable discussion on whether it might be
possible to discover and provide feedback to the application regarding
current link or path QoS being received. This might enable some form of
application adaptation.
In the case of the HDR system it was indicated that no such feedback is
currently available. Additionally, it was argued that this is in accord
with the current Internet stack model, which does not provide any mecha-
nisms to expose this type of information. Counter arguments stated that
there are growing demands in Internet QoS working groups requesting
exposure of this type of information via standardized APIs. Members
working on GPRS protocols also indicated frustration in deploying QoS
capabilities without exposure of this information. This clearly seemed a
topic for further investigations.
A final area of discussion on QoS discovery focused on the question of
how a server application might find out the capabilities of a receiver.
This could allow for application adaptation to client device and path
characteristics. One suggestion proposed use of RSVP payload, which is
able to transport QoS information. A second alternative is to push capa-
bility exchange and negotiation to the application layer. Discussion on
this topic was brief, as application issues were deemed outside the
workshop charter, however this also seems an area open for future inves-
tigation.
3.7 Discussion on Header Compression
A critical deterrent to Internet protocol adoption in the highly band-
width constrained wireless cellular environment is the bit overhead of
the protocol encoding. Examples presented highlighted how a voice appli-
cation (layered over IP [52,19], UDP [51], and RTP [57]) requires a min-
imum of 40 bytes of headers for IPv4 or 60 bytes for IPv6 before any
application payload (e.g., 24 byte voice sample). This overhead was also
presented as a contributing factor for the creation of WAP Wireless
Datagram Protocol (WDP) rather than IP for very low datarate bearers.
Discussion on header compression techniques to alleviate these concerns
focused on work being performed within the IETF Robust Header Compres-
sion (rohc) working group. This working group has established goals for
wireless environment, to conserve radio spectrum, to accommodate mobil-
ity, and to be robust to packet loss both before the point where com-
pression is applied and between compressor and decompressor. Additional
requirements established were that the technique be transparent, does
not introduce additional errors, and that it is compatible with common
D. Mitzel [Page 20]
Internet Draft IAB Wireless Workshop August 2000
protocol layerings (e.g., IPv4, IPv6, RTP/UDP/IP, TCP/IP).
The primary observation was that this problem is now largely solved!
The working group is currently evaluating the ROCCO [38] and ACE [42]
protocols, and expects to finalize its recommendations in the near
future. It was reported that these encodings have a minimum header of 1
byte and result in average overhead of less than 2 bytes for an
RTP/UDP/IP packet. There is some extra overhead required if transport
checksum is required and some issues still to be analyzed related to
interoperation with encryption and tunneling.
A detriment to IPv6 adoption often cited is its additional header over-
head, primarily attributed to its larger address size. A secondary
observation made was that it's believed that IPv6 accommodates greater
header compression than IPv4. This was attributed to the elimination of
the checksum and identification fields from the header.
Discussion on use of WWW protocols over wireless highlighted protocol
encodings as another potential detriment to their adoption. A number of
alternatives were mentioned for investigation, including use of a
"deflate" Content-Encoding, using compression with TLS [20], or
Bellovin's TCP filters. Observation was made that it could be beneficial
to investigate more compact alternative encoding of the WWW protocols.
3.8 Discussion on Applications Protocols
IETF protocol developments have traditionally taken the approach of pre-
ferring simple encode/decode and word alignment at the cost of some
extra bit transmissions. It was stated that optimizing protocol encoding
for bit savings often leads to shortcomings or limitations on protocol
evolution. However, it was also argued that environments where physical
limitations have an effect on transmission capacity and system perfor-
mance may present exceptions where optimized encodings are beneficial.
Cellular wireless and near-space satellite may fall into this category.
The WAP protocols exhibit several examples where existing Internet pro-
tocols were felt to be too inefficient for adoption with very low
datarate bearer services and limited capability devices. The WAP Wire-
less Session Protocol (WSP) is based on HTTPv1.1 [23], however WSP
incorporates several changes to address perceived inefficiencies. WSP
uses a more compact binary header encoding and optimizations for effi-
cient connection and capability negotiation. Similarly, the WAP Wire-
less Application Environment (WAE) uses tokenized WML and a tag-based
browser environment for more efficient operation.
Additional requests for more efficient and compact protocol encodings,
and especially improved capability negotiation were raised during dis-
cussion on usage of WWW protocols with wireless handheld devices.
D. Mitzel [Page 21]
Internet Draft IAB Wireless Workshop August 2000
Finally, work within the near-space satellite environment has pointed
out other physical limitations that can affect performance. In this case
the long propagation delays can make "chatty" protocols highly ineffi-
cient and unbearable for interactive use. This environment could benefit
from protocols that support some form of "pipelining" operation.
There seemed broad agreement that many of these observations represent
valid reasons to pursue optimization of protocol operations. Investiga-
tion of compact protocol encoding, capability negotiation, and minimiz-
ing or overlapping round trips to complete a transaction could all lead
to improved application performance across a wide range of environments.
3.9 Discussion on Proxy Agents
Proxy agents are present in a number of the wireless and mobile archi-
tectures. They're often required to gateway between communication
domains; terminate tunnel and translate between telephony system and
Internet protocols (GPRS), or to escape the "walled garden" (WAP). In
conjunction with limited capability handheld devices a proxy might be
deployed to offload expensive processing such as public key operations,
perform content filtering, or provide access to "backend" applications
(e.g., email, calendar, database). In other cases the proxy may be
required to work around protocol deployment limitations (e.g., NAT with
limited IPv4 addresses).
The discussion on proxy agents primarily recognized that there are a
range of proxy agent types. Proxies may operate by intercepting and
interpreting protocol packets, or by hijacking or redirecting connec-
tions. Some types of proxy break the Internet end-to-end communication
and security models. Other proxy architectures may limit system scala-
bility due to state or performance constraints. There was some desire
to conduct further study of proxy agent models to evaluate their effect
on system operation.
3.10 Discussion on Adoption of IPv6
Projections were presented claiming 1200 million cellular (voice) sub-
scribers, 600 million wired stations on the Internet, and over 600 mil-
lion wireless data ("web handset") users by the year 2004. Right up
front there was caution about these projections, especially the wireless
data since it is highly speculative with little history. Secondly,
there was some doubt regarding potential for significant revenues from
user base over 1 billion subscribers; this may be pushing the limits of
world population with sufficient disposable income to afford these
devices. However, there was broad consensus that cellular and Internet
services are going to continue rapid growth and that wireless data ter-
minals have potential to form a significant component of the total
Internet. These conclusions seemed to form the basis for many additional
D. Mitzel [Page 22]
Internet Draft IAB Wireless Workshop August 2000
recommendations to push for adoption of IPv6 protocols in emerging (3G)
markets.
In nearly all the presentations on 3G cellular network technologies dis-
cussion on scaling to support the projected large number of wireless
data users resulted in strong advocacy by the Internet representatives
for adoption of IPv6 protocols. There were some positive signs that
groups have begun investigation into IPv6. For example, 3GPP has already
defined IPv6 as an option in their 1998 and 1999 specifications (release
R98 and R99), and are considering specifying IPv6 as mandatory in the
release 2000. The MWIF effort is also cognizant of IPv4 and IPv6 issues
and is currently wrestling with their recommendations in this area.
Although there was limited positive signs on IPv6 awareness, indication
is that there are long fights ahead to gain consensus for IPv6 adoption
in any of the 3G standards efforts. There was considerable feedback that
the telephony carriers perceive IPv6 as more difficult to deploy,
results in higher infrastructure equipment expenses, and adds difficulty
in interoperation and gatewaying to the current (IPv4) Internet. Argu-
ments for sticking with IPv4 primarily came down to the abundance and
lower pricing of IPv4-based products, and secondary argument of risk
aversion; there is currently minimal IPv6 deployment or operational
experience and expertise, and the carriers do not want to drive develop-
ment of this expertise. Finally, some groups argue IPv4 is sufficient
for "walled garden" use, using IPv4 private address space (i.e., the
"net 10" solution).
One other area of concern regarding IPv6 usage is perceived memory and
processing overhead and its effect on small, limited capability devices.
This was primarily directed at IPv6 requirement for IPsec implementation
to claim conformance. Arguments that continued increase in device capac-
ity will obviate these concerns were rejected. It was stated that power
constraints on these low-end devices will continue to force concerns on
memory and processing overhead, and impact introduction of other fea-
tures. There was no conclusion on whether IPsec could be made optional
for these devices, or the effect if these devices were "non-compliant".
Emerging 3G cellular networks appear ideal environment for IPv6 intro-
duction. IPv6 addresses scaling requirements of wireless data user pro-
jections and eliminates continued cobbling of systems employing (IPv4)
private address space and NAT. This appears an area for IAB and Internet
community to take a strong stance advocating adoption of IPv6 as the
various 3G forums wrestle with their recommendations.
3.11 Discussion on Signaling
Discussion on signaling focused on call setup and control functions, and
the effects of mobility. The 3G.IP group has investigated standardizing
D. Mitzel [Page 23]
Internet Draft IAB Wireless Workshop August 2000
on either H.323 [32] or SIP [30]. Currently support seems to be split
between the protocols, and neither seemed ideal without support for
mobility. During discussion on VoIP it was presented that SIP does sup-
port mobility, with graceful handling of mobile handoff, updating loca-
tion information with remote peer, and even simultaneous handoff of both
endpoints. The problem with SIP adoption seems to be its slow standard-
ization brought about by focusing on the harder multicast model rather
than expediting definition of a unicast "profile". There seems great
need for IETF to expedite finalization of SIP, however some argued at
this point it's likely many products will need to develop support for
both SIP and H.323, and for their interoperation.
A short discussion was also raised on whether it is the correct model to
incorporate the additional protocol mechanisms to accommodate mobility
into the SIP signaling. An alternative model might be to build on top of
the existing mobile IP handoff facilities. There was no conclusion
reached, however it seemed an area for further investigation.
3.12 Discussion on Interactions Between IETF and Other Standards Organi-
zations
There were many examples where non-IETF standards organizations would
like to directly adopt IETF standards to enable Internet (or similar)
services. For example IEEE 802.11 WLAN relies on adoption of IETF stan-
dards for mobile IP, end-to-end security, and AAA services. 3GPP is
looking into the IETF work on header compression. WAPF derived its
transport, security, and application environment from Internet proto-
cols. At first glance these would seem successes for adoption of Inter-
net technologies, however the decision to rely on IETF standards often
introduced frustrations too.
One common theme for frustration is differences in standardization pro-
cedures. For instance, 3GPP follows a strict model of publishing recom-
mendations yearly; any feature that cannot be finalized must be dropped.
On the other hand the IETF working groups have much less formalized
schedules, and in fact often seem to ignore published milestone dates.
This has led to a common perception within other standards organizations
that the IETF cannot deliver [on time].
A second area identified where IETF differs from other organizations is
in publication of "system profile". For example defining interoperation
of IPsec, QoS for VoIP and video conferencing, and billing as a "ser-
vice". Wading through all the protocol specifications, deciding on
optional features and piecing together the components to deliver a com-
mercial quality service takes considerable expertise.
Thirdly, there was often confusion about how to get involved in IETF
standards effort, submit requirements, and get delivery commitments.
D. Mitzel [Page 24]
Internet Draft IAB Wireless Workshop August 2000
Many people seem unaware and surprised at how open and simple it is to
join in IETF standardization via working group meetings and mailing
list.
There wasn't really a large amount of discussions on ways to address
these differences in standards practices. However, it did seem benefi-
cial to understand these concerns and frustrations. It seemed clear
there can be some benefits in improving communication with other stan-
dards organizations and encouraging their participation in IETF activi-
ties.
4 Recommendations
The IAB wireless workshop provided a forum for those in the Internet
research community and in the wireless and telephony community to meet,
exchange information, and discuss current activities on using Internet
technology in wireless environments. However the primary goal from the
perspective of the IAB was to reach some understanding on any problems,
both technical or perceived deficiencies, deterring the adoption of
Internet protocols in this arena. This section documents recommendations
of the workshop on actions by the IAB and IESG, IRTF research efforts,
and protocol development actions for the IETF to address these current
deficiencies and foster wider acceptance of Internet technologies.
4.1 Recommendations on Fostering Interaction with Non-Internet Standards
Organizations
A clear consensus of the workshop is that dialog needs to be improved.
The Internet community should attempt to foster communication with other
standards bodies, including WAPF, MWIF, 3GPP, 3G.IP, etc. The goal is
to "understand each others problems", provide for requirements input,
and greater visibility into the standardization process.
4.1.1
It was recommended to take a pragmatic approach rather than formalizing
liaison agreements. The formalized liaison model is counter to the
established Internet standards process, is difficult to manage, and has
met with very limited success in previous trials. Instead, any relevant
IETF working group should be strongly encouraged to consider and recom-
mend potential liaison requirements within their charter.
4.1.2
It was recommended to avoid formation of jointly sponsored working
groups and standards. Once again this has shown limited success in the
past. The preferred mode of operation is to maintain separate standards
organizations but to encourage attendance and participation of external
D. Mitzel [Page 25]
Internet Draft IAB Wireless Workshop August 2000
experts within IETF proceedings and to avoid overlap.
An exception to this style of partitioning meeting sponsorship is less
formal activities, such as BOFs. It was recommended that sponsoring
joint BOF could be beneficial. These could enable assembly of experts
from multiple domains early in the process of exploring new topics for
future standards activities.
4.1.3
A principle goal of fostering communication with other standards organi-
zations is mutual education. To help in achieving this goal recommenda-
tions were made related to documenting more of the history behind Inter-
net standards and also in coordinating document reviews.
It was recommended that IETF standards groups be encouraged to create or
more formally document the reasons behind algorithm selection and design
choices. Currently much of the protocol design history is difficult to
extract, in the form of working group mail archives or presentations.
Creation of these documents could form the basis to educate newcomers
into the "history" and wisdom behind the protocols.
It was recommended that mutual document reviews should be encouraged.
This helps to disseminate information on current standards activities
and provides an opportunity for external expert feedback. A critical
hurdle that could severely limit the effectiveness of this type of
activity is the intellectual property and distribution restrictions some
groups place on their standards and working documents.
4.2 Recommendations for Dealing with "Walled Garden" Model
There are several perceived benefits to the "walled garden" (captive
customer) model, similar to current deployment of "intranets". These
range from simplified user security to "captive customer" economic mod-
els. There was disagreement on the extent this deployment model might be
perpetuated in the future. However it is important to recognize this
model exists and to make a conscious decision on how to accommodate it
and how it will affect protocol design.
4.2.1
It was strongly recommended that independent of the ubiquity of the
"walled garden" deployment scenario that protocols and architectural
decisions should not target this model. To continue the success of
Internet protocols at operating across a highly diverse and heteroge-
neous environment the IETF must continue to foster the adoption of an
"open model". IETF protocol design must address seamless, secure, and
scalable access.
D. Mitzel [Page 26]
Internet Draft IAB Wireless Workshop August 2000
4.2.2
Recognition that the "walled garden" model has some perceived benefits
led to recommendations to better integrate it into the Internet archi-
tecture. These focused on service location and escape from the "walled
garden".
It was recommended to investigate standard protocols for service and
proxy discovery within the "walled garden" domain. There are already a
number of candidate mechanisms, including static preconfiguration, DNS
[22,27,44,45], BOOTP [18], DHCP [21], SLP [28], and others. Specific
recommendations on use of these protocols in this environment can help
foster common discovery methods across a range of access devices and
ease configuration complexity.
It was recommended to investigate standard methods to transport through
the garden wall (e.g., escape to the Internet). It seemed clear that a
better model is required than trying to map all access over a HTTP [23]
transport connection gateway. One suggestion was to propose use of IP!
4.3 Recommendations on IPv4 and IPv6 Scaling
Wireless operators are projecting supporting on the order of 10's to
100's million users on their Internet-based services. Supporting this
magnitude of users could have severe scaling implications on use of the
dwindling IPv4 address space.
4.3.1
There was clear consensus that any IPv4-based model relying on tradi-
tional stateless NAT technology [60] is to be strongly discouraged. NAT
has several inherent faults, including breaking the Internet peer-to-
peer communication model, breaking end-to-end security, and stifling
deployment of new services [16,29,31]. In addition, the state and per-
formance implications of supporting 10's to 100's million users is cost
and technologically prohibitive.
4.3.2
Realm specific IP (RSIP) [10,11] has potential to restore the end-to-end
communication model in the IPv4 Internet, broken by traditional NAT.
However there was considerable reluctance to formally recommend this as
the long term solution. Detriments to its adoption include that the
protocol is still being researched and defined, and potential interac-
tions with applications, QoS features, and security remain. In addition,
added signaling, state, and tunneling has cost and may be technologi-
cally prohibitive scaling.
D. Mitzel [Page 27]
Internet Draft IAB Wireless Workshop August 2000
4.3.3
The clear consensus of the workshop was to recommend adoption of an
IPv6-based solution to support these services requiring large scaling.
Adoption of IPv6 will aid in restoring the Internet end-to-end communi-
cation model and eliminates some roaming issues. Adoption of IPv6 in
this marketspace could also help spur development of IPv6 products and
applications, and hasten transition of the Internet. It was recognized
that some application gateways are required during transition of the
IPv4 Internet, however it was felt that the scaling and roaming benefits
outweighed these issues.
4.3.4
It was recommended that an effort be made to eliminate any requirement
for NAT in an IPv6 Internet. The IAB believes that the IPv6 address
space is large enough to preclude any requirement for private address
allocation [55] or address translation due to address space shortage
[15]. Therefore, accomplishing this should primarily require installing
and enforcing proper address allocation policy on registry and service
providers. It was recommended to establish policies requiring service
providers to allocate a sufficient quantity of global addresses for a
sites use. The feeling was that NAT should be easily eliminated provided
efficient strategies are defined to address renumbering [17,62] and
mobility [37] issues.
4.4 Recommendations on IPv4 and IPv6 Mobility
An inherent characteristic of wireless systems is their potential for
accommodating device roaming and mobility. Scalable and efficient sup-
port of this mobility within Internet protocols can aid in pushing
native IP services out to the mobile devices.
4.4.1
Several limitations were identified relating to current specification of
mobile IPv4 [48]. Primary among these limitations is that mechanisms to
support redundant home agents and failover are not currently defined.
Redundant home agents are required to avoid single point of failure,
which would require (proprietary) extensions. Additional deficiencies
related to lack of route optimization, and tunneling and path MTU issues
were also identified. Due to these limitations there was reluctance to
recommend this as a solution.
4.4.2
It was recommended to encourage adoption of IPv6 mobility extensions
[37] to support roaming capabilities in the wireless environment. IP
D. Mitzel [Page 28]
Internet Draft IAB Wireless Workshop August 2000
mobility over IPv6 incorporates improvements to address several limita-
tions of the IPv4-based mobility. The ability to use autoconfiguration
for "care of" address improves robustness and efficiency. Additionally,
path MTU is more easily adapted when a router forwards to a new "care
of" address.
Building wireless roaming atop IPv6-based mobility may introduce
IPv4/IPv6 transition issues unique to the mobile environment. It was
recommended to add investigation of these issues to the charter of the
existing IETF Next Generation Transition (ngtrans) working group, pro-
vided any mobile IP interoperation issues be identified.
4.4.3
Scalable and widespread authentication, authorization, and accounting
(AAA) services are critical to the deployment of commercial services
based on (wireless) mobile IP. Some work is progressing on definition of
these standards for IP mobility [26,49]. However, due to the pivotal
role of these protocols on the ability to deploy commercial services, it
was recommended to make finalization of these AAA standards and investi-
gation of AAA scalability as high priorities.
4.5 Recommendations on TCP and Transport Protocols
The wireless environment and applications place additional requirements
on transport protocol. Unique link error and performance characteris-
tics, and application sensitivity to connection setup and transaction
semantics has led to "optimized" transports specific to each environ-
ment. These new transports often lack robustness found in Internet
transport and place barriers to seamless gatewaying to the Internet. It
was felt that better education on transport design and cooperation on
Internet transport evolution could lead to significant improvements.
4.5.1
It was recommended that the IETF Transport Area (tsv) working group doc-
ument why Internet transport protocols are the way they are. The focus
should be on generic transport issues and mechanisms, rather than TCP
specifics. This should capture usage and tradeoffs in design of specific
transport mechanisms (e.g., connection establishment, congestion con-
trol, loss recovery strategies, etc.), and document some of the history
behind transport research in the Internet.
This "entry point" document into transport design is in direct support
of the recommendations in section 4.1 to foster communication and mutual
education. In addition it was deemed critical that the Internet commu-
nity make it very clear that congestion control is not optional. Inter-
net researchers have learned that optimizing for a single link or
D. Mitzel [Page 29]
Internet Draft IAB Wireless Workshop August 2000
homogeneous environment does not scale. Early work by Jacobson [34,35],
standardization of TCP congestion control [5], and continuing work
within the IETF Endpoint Congestion Management (ecm) working group could
provide excellent basis for education of wireless transport designers.
4.5.2
It was recommended that the IETF actively solicit input from external
standards bodies on identifying explicit requirements and in assessing
inefficiencies in existing transports in support of cellular and wire-
less environments. This has proven highly effective in identifying
research topics and in guiding protocol evolution to address new opera-
tional environments, for instance in cooperation with groups doing
satellite-based internetworking [4,6].
4.5.3
It was recommended that the IAB make wireless standards bodies aware of
the existence, and get them active in, the IETF Transport Area (tsv)
working group. This transport "catch all" could provide an excellent
forum for workers outside the Internet community to propose ideas and
requirements, and engage in dialog with IESG members prior to contribut-
ing any formal proposal into the IETF or incurring overhead of working
group formation.
4.5.4
Mobile radio environments may often be subject to frequent temporary
outages. For example, roaming through an area that is out of range of
any base station, or disruptions due to base station handoffs. This vio-
lation of the congestive loss assumption of TCP can have severe detri-
mental effect on transport performance. It was recommended to investi-
gate mechanisms for improving transport performance when these non-con-
gestive loss can be detected. Areas for potential research identified
include incorporation of "hints" to the sender providing Non-Congestive
Loss Indication (NCLI) or stimulating transmission after link recovery
via Source Encourage (SE) message [39]. This likely falls to the auspice
of the IETF Performance Implications of Link Characteristics (pilc)
working group.
4.5.5
Many wireless applications require transaction semantics and are highly
sensitive to connection establishment delays (e.g., WAP). However, it
is still desirable to efficiently support streaming of large bulk trans-
fers too. It was recommended to investigate tradeoffs in supporting
these transaction and streaming connections. Potential areas for inves-
tigation include tradeoffs between minimal transaction transport and
D. Mitzel [Page 30]
Internet Draft IAB Wireless Workshop August 2000
potential security and denial of service (DoS) attacks, mechanisms to
piggyback data during connection establishment to eliminate round trip
delays, or ways for endpoints to cooperate in eliminating setup hand-
shake for simple transactions while providing switchover to reliable
streaming for bulk transfers.
4.5.6
It was recommended to look at (TCP) transport improvements specific to
the wireless and mobile environment. An example is to investigate reat-
tachable transport endpoints. This could allow for graceful recovery of
a transport connection after a roaming or mobility event results in
changes to one or both endpoint identifiers. Another area for potential
investigation is to develop targeted uses of D-SACK [25]. D-SACK pro-
vides additional robustness to reordered packets, which may prove bene-
ficial in wireless environment where packets are occasionally corrupted.
Higher performance may be attainable by eliminating requirements on
link-level retransmission maintaining in-order delivery within a flow.
4.6 Recommendations on Routing
Unique routing requirements may be introduced in support of wireless
systems, especially when viewing the mobile component as an autonomous
system (AS).
4.6.1
It was recommended that the IETF Routing Area commence investigation of
extensions to the BGP protocol [54] to support additional policy fea-
tures available within the ISO IDRP protocol [33]. The range of policy
control desired includes adopting different identity or policies based
on current point of attachment, and providing flexibility in path selec-
tion based on local policy and/or current peer policy. These features
could be used for instance in support of requirements established in the
Aeronautical Telecommunication Network (ATN).
4.6.2
It was recommended that the IETF Routing Area commence investigation of
extensions to the BGP protocol [54] to support additional QoS/TOS path
selection features available within the ISO IDRP protocol [33]. The
range of policies include differentiating service level or path selec-
tion based on traffic classes. An example, based on Aeronautical
Telecommunication Network (ATN) requirements, might be differentiating
path selection and service between airline control and passenger enter-
tainment traffic.
D. Mitzel [Page 31]
Internet Draft IAB Wireless Workshop August 2000
4.7 Recommendations on Mobile Host QoS Support
Wireless link bandwidth is often scarce (e.g., cellular) and/or shared
(e.g., IEEE 802.11 WLAN). Meeting application QoS needs requires accom-
modating these link characteristic, in addition to the roaming nature of
mobile host. Specialized support may be required from the network layer
to meet both link and end-to-end performance constraints.
4.7.1
It was recommended that the IETF Transport Area undertake investigation
into providing QoS in the last leg of mobile systems. That is, between
the mobile device and the network access point. This type of QoS support
might be appropriate where the wireless link is the most constrained
resource. A potential solution to investigate is to employ an explicit
reservation mechanism between the mobile host and the access point
(e.g., RSVP [13]), while relying on resource provisioning or more scal-
able DiffServ [9] technologies within the core.
4.7.2
It was recommended that the IETF Transport Area undertake investigation
into end-to-end QoS when the path includes a mixture of wireless and
wired technologies. This investigation could focus on mechanism to com-
municate QoS characteristics in cellular network to the core network to
establish end-to-end QoS guarantees. An alternative investigation is to
look into discovery problem of assessing current end-to-end performance
characteristics, enabling for dynamic adaptation by mobile host.
4.8 Recommendations on Application Mobility
In a mobile environment with roaming, and mobile host disconnect and
reconnect at different attachment point it may be desirable to recover
an incomplete application session. It was recommended that the IRTF
investigate application mobility at this level. The goal is to achieve a
smooth recovery after a disconnect period; something more graceful than
a "redial". Currently there does not appear to be sufficient information
available within the network stack, this may require instantiation of
some form of "session" layer.
4.9 Recommendations on TCP/IP Performance Characterization in WAP-like
Environment
WAPF has gone to considerable effort to develop unique transport proto-
col and optimizations due to perception that TCP/IP protocol stack is
too expensive. Much of this was predicated on WAP requirements to sup-
port very low datarate bearer services. It was recommended that members
of the IRTF evaluate TCP/IP stack performance in WAP-like environment to
D. Mitzel [Page 32]
Internet Draft IAB Wireless Workshop August 2000
quantify its behavior and applicability. The focus should include
investigation of code and memory space requirements, as well as link
usage to complete a single transaction for current WAP protocols and for
both IPv4 and IPv6. This work should result in better characterization
of TCP/IP performance in highly constrained devices and network, recom-
mendations to the IETF on protocol enhancements to optimize performance
in this environment, and recommendations to WAPF on suitability of
deploying native IP protocols.
4.10 Recommendations on Protocol Encoding
IETF protocol developments have traditionally taken the approach of pre-
ferring simple encode/decode and word alignment at the cost of some
extra bit transmissions. This overhead may prove too burdensome in some
bandwidth constrained environments, such as cellular wireless and WAP.
Work within the IETF Robust Header Compression (rohc) working group may
go a long way to reducing some of these detriments to Internet protocols
deployment. However, there may be potential for additional savings from
investigation of alternative encoding of common Internet protocols. It
was recommended that members of the IRTF evaluate general techniques
that can be used to reduce protocol "verbiage". Examples might include
payload compression techniques or tokenized protocol encoding.
4.11 Recommendations on Inter-Domain AAA Services
Commercial roaming and mobility services are likely to require exchange
of authentication, authorization, and billing services spanning multiple
domains (service providers). This introduces requirements related to
establishing a web or hierarchy of trust across multiple autonomous
domains. Standard protocols to specify and exchange usage policies and
billing information must also be established. Some work is progressing
on scoping out the issues and a framework [7,64]. However, there are
significant issues to be solved to enable a scalable, Internet-wide
solution. Due to the pivotal role of these protocols on the ability to
deploy commercial services, it was recommended to make finalization of
scalable inter-domain AAA as high priority within the IETF.
4.12 Recommendations on Bluetooth
Bluetooth protocols and devices were originally optimized for a narrow
application space. However, there is interest in exploring the breadth
to which protocol and device access can be extended. One particular area
of interest is exploring integration into, or gatewaying access to, the
Internet. It was recommended that the IETF pursue formation of a joint
BOF to assemble experts from the IETF and Bluetooth communities to begin
exploration of this problem. This is in direct support of the recommen-
dations in section 4.1 to foster communication and mutual education.
D. Mitzel [Page 33]
Internet Draft IAB Wireless Workshop August 2000
4.13 Recommendations on Proxy Architecture
Proxy agents are often deployed to intercept and evaluate protocol
requests (e.g., web cache, HTTP redirector, filtering firewall) or to
gateway access between communication domains (e.g., traversing bastion
host between private network and Internet or gatewaying between a cellu-
lar service and the Internet). There are a number of potential architec-
tures when contemplating development and deployment of one of these
proxy agent. It was recommended that members of the IRTF investigate
taxonomy of proxy architectures and evaluate their characteristics and
applicability. Each type of proxy should be characterized, for example,
by its effect on Internet end-to-end model, and security, scaling, and
performance implications. The results of this study can help educate
developers and network operators on the range of proxy available and
recommend solutions that are least disruptive to Internet protocols.
4.14 Recommendations on Justifying IPv6-based Solutions for Mobile /
Wireless Internet
IPv6 was strongly recommended to address scaling (see section 4.3) and
mobility (see section 4.4) issues in the future Internet dominated by
large numbers of wireless and mobile devices. It was recommended that
the IAB draft a formalized justification for these recommendations for
adoption of IPv6-based solution. It was believed that the "The Case for
IPv6" [40] document should form an excellent basis for this justifica-
tion. In addition, documents highlighting architectural and operational
pitfalls of continued reliance on IPv4 and NAT also provide excellent
justification [29,31,59]. It was deemed urgent to submit these informa-
tional documents as inputs to other standards bodies (MWIF, 3GPP,
3G.IP), as many decisions are being made on Internet protocol adoption
and this data could be highly influential.
5 Security Considerations
This workshop did not focus on security. However, mobility and wireless
environment introduces additional complexities for security and poten-
tial attacks to user authentication and privacy. The presentations by
Asokan and by Calhoun referenced in section 2 focused on security mecha-
nisms in currently deployed cellular networks and evolution toward 3G
cellular and IP networks. Discussion on the "walled garden" service
model (see section 3.1) briefly mentions effects on simplifying security
requirements. Section 3.3 raises a number of security issues related to
wireless devices and mobility. These include alternatives for establish-
ing user identity and capabilities, securing network infrastructure from
attacks, and security associations required for mobile IP and AAA opera-
tion. Section 3.7 mentions interoperation issues between compression
and encryption or tunneling, and finally section 3.9 highlight potential
for proxy agent to be used to offload expensive crypto operations.
D. Mitzel [Page 34]
Internet Draft IAB Wireless Workshop August 2000
6 Acknowledgments
The author would like to thank all of the workshop participants for
their feedback, encouragement, and patience during the writeup of this
document. I would especially like to thank Brian Carpenter for prompt
responses to questions on the document organization and content. Simi-
larly, Charlie Perkins provided extensive feedback that dramatically
improved and corrected statements throughout the report. Finally, Mikael
Degermark, Sally Floyd, Heikki Hammainen, Geoff Huston, and Gabriel Mon-
tenegro contributed comments and responses to questions.
7 Bibliography
[1] ACIRI. TCP-Friendly Rate Control. http://www.aciri.org/tfrc.
[2] A. Aggarwal, S. Savage, and T. Anderson. Understanding the Perfor-
mance of TCP Pacing. Proceedings of IEEE Infocom 2000, March 2000.
[3] M. Allman, S. Floyd, and C. Partridge. Increasing TCP's Initial
Window. Internet Request for Comments, RFC-2414, September 1998.
[4] M. Allman, D. Glover, and L. Sanchez. Enhancing TCP Over Satellite
Channels using Standard Mechanisms. Internet Request for Comments,
RFC-2488, January 1999.
[5] M. Allman, V. Paxson, and W. Stevens. TCP Congestion Control.
Internet Request for Comments, RFC-2581, April 1999.
[6] M. Allman, et al. Ongoing TCP Research Related to Satellites.
Internet Request for Comments, RFC-2760, February 2000.
[7] J. Arkko. Requirements for Internet-Scale Accounting Management.
Internet Draft, draft-arkko-acctreqlis-00.txt, August 1998 (work in
progress).
[8] T. Bates, R. Chandra, D. Katz, and Y. Rekhter. Multiprotocol Exten-
sions for BGP-4. Internet Request for Comments, RFC-2283, February
1998.
[9] S. Blake, et al. An Architecture for Differentiated Services.
Internet Request for Comments, RFC-2475, December 1998.
[10] M. Borella, et al. Realm Specific IP: Framework. Internet Draft,
draft-ietf-nat-rsip-framework-04.txt, March 2000 (work in progress).
[11] M. Borella, et al. Realm Specific IP: Protocol Specification.
Internet Draft, draft-ietf-nat-rsip-protocol-06.txt, March 2000 (work in
progress).
D. Mitzel [Page 35]
Internet Draft IAB Wireless Workshop August 2000
[12] R. Braden. T/TCP -- TCP Extensions for Transactions Functional
Specification. Internet Request for Comments, RFC-1644, July 1994.
[13] R. Braden, et al. Resource ReSerVation Protocol (RSVP) -- Version
1 Functional Specification. Internet Request for Comments, RFC-2205,
September 1997.
[14] S. Brim, B. Carpenter, and F Le Faucheur. Per Hop Behavior Identi-
fication Codes. Internet Request for Comments, RFC-2836, May 2000.
[15] B. Carpenter, J. Crowcroft, and Y. Rekhter. IPv4 Address Behaviour
Today. Internet Request for Comments, RFC-2101, February 1997.
[16] B. Carpenter. Internet Transparency. Internet Request for Com-
ments, RFC-2775, February 2000.
[17] M. Crawford. Router Renumbering for IPv6. Internet Draft, draft-
ietf-ipngwg-router-renum-10.txt, March 2000 (work in progress).
[18] B. Croft and John Gilmore. Bootstrap Protocol (BOOTP). Internet
Request for Comments, RFC-951, September 1985.
[19] S. Deering and R. Hinden. Internet Protocol, Version 6 (IPv6)
Specification. Internet Request for Comments, RFC-2460, December 1998.
[20] T. Dierks and C. Allen. The TLS Protocol Version 1.0. Internet
Request for Comments, RFC-2246, January 1999.
[21] R. Droms. Dynamic Host Configuration Protocol. Internet Request
for Comments, RFC-2131, March 1997.
[22] C. Everhart, et al. New DNS RR Definitions. Internet Request for
Comments, RFC-1183, October 1990.
[23] R. Fielding, et al. Hypertext Transfer Protocol -- HTTP/1.1.
Internet Request for Comments, RFC-2616, June 1999.
[24] S. Floyd and T. Henderson. The NewReno Modification to TCP's Fast
Recovery Algorithm. Internet Request for Comments, RFC-2582, April
1999.
[25] S. Floyd, et al. An Extension to the Selective Acknowledgment
(SACK) Option for TCP. Internet Draft, draft-floyd-sack-00.txt, Febru-
ary 2000 (work in progress).
[26] S. Glass, et al. Mobile IP Authentication, Authorization, and
Accounting Requirements. Internet Draft, draft-ietf-mobileip-aaa-
reqs-03.txt, March 2000 (work in progress).
D. Mitzel [Page 36]
Internet Draft IAB Wireless Workshop August 2000
[27] A. Gulbrandsen and P. Vixie. A DNS RR for specifying the location
of services (DNS SRV). Internet Request for Comments, RFC-2052, October
1996.
[28] E. Guttman, et al. Service Location Protocol, Version 2. Internet
Request for Comments, RFC-2608, June 1999.
[29] T. Hain. Architectural Implications of NAT. Internet Draft,
draft-iab-nat-implications-05.txt, February 2000 (work in progress).
[30] M. Handley, et al. SIP: Session Initiation Protocol. Internet
Request for Comments, RFC-2543, March 1999.
[31] M. Holdrege and P. Srisuresh. Protocol Complications with the IP
Network Address Translator (NAT). Internet Draft, draft-ietf-nat-proto-
col-complications-02.txt, March 2000 (work in progress).
[32] International Telecommunication Union. Visual Telephone Systems
and Equipment for Local Area Networks which provide a Non-guaranteed
Quality of Service. Recommendation H.323, May 1996.
[33] ISO/IEC. Protocol for Exchange of Inter-Domain Routeing Informa-
tion among Intermediate Systems to support Forwarding of ISO 8473 PDUs.
ISO/IEC IS10747, 1993.
[34] V. Jacobson. Congestion Avoidance and Control. Computer Communi-
cation Review, vol. 18, no. 4 August 1988.
ftp://ftp.ee.lbl.gov/papers/congavoid.ps.Z.
[35] V. Jacobson. Modified TCP Congestion Avoidance Algorithm.
end2end-interest mailing list, April 30, 1990.
ftp://ftp.isi.edu/end2end/end2end-interest-1990.mail.
[36] V. Jacobson, R. Braden, and D. Borman. TCP Extensions for High
Performance. Internet Request for Comments, RFC-1323, May 1992.
[37] D. Johnson and C. Perkins. Mobility Support in IPv6. Internet
Draft, draft-ietf-mobileip-ipv6-12.txt, April 2000 (work in progress).
[38] L. Jonsson, et al. RObust Checksum-based header COmpression
(ROCCO). Internet Draft, draft-ietf-rohc-rtp-rocco-00.txt, May 2000
(work in progress).
[39] P. Karn, et al. Advice for Internet Subnetwork Designers. Inter-
net Draft, draft-ietf-pilc-link-design-02.txt, March 2000 (work in
progress).
D. Mitzel [Page 37]
Internet Draft IAB Wireless Workshop August 2000
[40] S. King, et al. The Case for IPv6. Internet Draft, draft-iab-
case-for-ipv6-05.txt, October 1999 (work in progress).
[41] J. Kulik, R. Coulter, D. Rockwell, and C. Partridge. Paced TCP for
High Delay-Bandwidth Networks. Proceedings of IEEE Globecom '99, Decem-
ber 1999.
[42] K. Le, et al. Adaptive Header ComprEssion (ACE) for Real-Time Mul-
timedia. Internet Draft, draft-ietf-rohc-rtp-ace-00.txt, May 2000 (work
in progress).
[43] M. Mathis, J. Mahdavi, S. Floyd, and A. Romanow. TCP Selective
Acknowledgment Options. Internet Request for Comments, RFC-2018, Octo-
ber 1996.
[44] P. Mockapetris. Domain Names -- Concepts and Facilities. Internet
Request for Comments, RFC-1034, STD0013, November 1987.
[45] P. Mockapetris. Domain Names -- Implementation and Specification.
Internet Request for Comments, RFC-1035, STD0013, November 1987.
[46] K. Nichols, S. Blake, F. Baker, and D. Black. Definition of the
Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers.
Internet Request for Comments, RFC-2474, December 1998.
[47] C. Partridge, T. Mendez, and W. Milliken. Host Anycasting Service.
Internet Request for Comments, RFC-1546, November 1993.
[48] C. Perkins. IP Mobility Support. Internet Request for Comments,
RFC-2002, October 1996.
[49] C. Perkins and P. Calhoun. AAA Registration Keys for Mobile IP.
Internet Draft, draft-ietf-mobileip-aaa-key-01.txt, January 2000 (work
in progress).
[50] C. Perkins and D. Johnson. Route Optimization in Mobile IP.
Internet Draft, draft-ietf-mobileip-optim-09.txt, February 2000 (work in
progress).
[51] J. Postel. User Datagram Protocol. Internet Request for Comments,
RFC-768, STD0006, August 1980.
[52] J. Postel. Internet Protocol. Internet Request for Comments,
RFC-791, STD0005, September 1981.
[53] K. Ramakrishnan and S. Floyd. A Proposal to add Explicit Conges-
tion Notification (ECN) to IP. Internet Request for Comments, RFC-2481,
January 1999.
D. Mitzel [Page 38]
Internet Draft IAB Wireless Workshop August 2000
[54] Y. Rekhter and T. Li. A Border Gateway Protocol 4 (BGP-4). Inter-
net Request for Comments, RFC-1771, March 1995.
[55] Y. Rekhter, et al. Address Allocation for Private Internets.
Internet Request for Comments, RFC-1918, BCP0005, February 1996.
[56] C. Rigney, A. Rubens, W. Simpson, and S. Willens. Remote Authenti-
cation Dial In User Service (RADIUS). Internet Request for Comments,
RFC-2138, April 1997.
[57] H. Schulzrinne, et al. RTP: A Transport Protocol for Real-Time
Applications. Internet Request for Comments, RFC-1889, January 1996.
[58] J. Semke, J. Mahdavi, and M. Mathis. Automatic TCP Buffer Tuning.
Proceedings of ACM SIGCOMM '98, September 1998.
[59] P. Srisuresh and M. Holdrege. IP Network Address Translator (NAT)
Terminology and Considerations. Internet Request for Comments,
RFC-2663, August 1999.
[60] P. Srisuresh and K. Egevang. Traditional IP Network Address Trans-
lator (Traditional NAT). Internet Draft, draft-ietf-nat-tradi-
tional-04.txt, April 2000 (work in progress).
[61] R. Steward, et al. Stream Control Transmission Protocol. Internet
Draft, draft-ietf-sigtran-sctp-09.txt, April 2000 (work in progress).
[62] S. Thomson and T. Narten. IPv6 Stateless Address Autoconfigura-
tion. Internet Request for Comments, RFC-2462, December 1998.
[63] J. Touch. TCP Control Block Interdependence. Internet Request for
Comments, RFC-2140, April 1997.
[64] J. Vollbrecht, et al. AAA Authorization Framework. Internet
Draft, draft-ietf-aaa-authz-arch-00.txt, October 1999 (work in
progress).
A Participants
Juha Ala-Laurila JUHA.ALA-LAURILA@nokia.com
Mark Allman mallman@grc.nasa.gov
Alastair Angwin angwin@uk.ibm.com
N. Asokan n.asokan@nokia.com
Victor Bahl bahl@microsoft.com
Fred Baker fred@cisco.com
Pravin Bhagwat pravinb@us.ibm.com
Scott Bradner sob@harvard.edu
D. Mitzel [Page 39]
Internet Draft IAB Wireless Workshop August 2000
Randy Bush randy@psg.com
Pat Calhoun Pcalhoun@eng.sun.com
Brian Carpenter brian@icair.org
Mikael Degermark micke@cs.arizona.edu
Sally Floyd floyd@aciri.org
Heikki Hammainen HEIKKI.HAMMAINEN@NOKIA.COM
Mark Handley mjh@aciri.org
Bob Hinden hinden@iprg.nokia.com
Christian Huitema huitema@microsoft.com
Chih-Lin I ci@att.com
Van Jacobson van@packetdesign.com
Phil Karn Karn@qualcomm.com
John Klensin Klensin@JCK.com
Jerry Lahti jerry.lahti@nokia.com
Allison Mankin mankin@isi.edu
Danny J. Mitzel mitzel@iprg.nokia.com
Gabriel Montenegro gab@sun.com
Keith Moore moore@cs.utk.edu
Eric Nordmark nordmark@sun.com
Charles E. Perkins charliep@iprg.nokia.com
Jonne Soininen jonna.Soininen@nokia.com
Chris A. Wargo cwargo@cnsw.com
Lars Westberg Lars.Westberg@era.ericsson.se
Lixia Zhang lixia@cs.ucla.edu
B Author's Address
Danny J. Mitzel
Nokia
313 Fairchild Drive
Mountain View, CA 94043
USA
Phone: +1 650 625 2037
Email: mitzel@iprg.nokia.com
C Changes from draft-iab-wirelessws-00.txt
+ incorporated fixes for mostly minor grammatical errors and some
statement clarifications throughout the draft. these affect many
subsections of both discussion and recommendations, but no sub-
stantive changes to document recommendations.
D. Mitzel [Page 40]
Internet Draft IAB Wireless Workshop August 2000
+ incorporated comments from geoff huston on non-congestive loss
indication in section 3.4. mostly adding discussion on general
mechanism to more closely tie layer 2 (link layer) status signal-
ing to TCP transport operation.
+ renamed routing policy discussion section (section 3.5) to "Dis-
cussion on Aeronautical Telecommunication Network (ATN) Routing
Policy" to indicate its primary focus on ATN routing require-
ments.
+ slight wording changes to routing recommendations in section 4.6.
rather than targeting ATN explicitly, state recommendations as
embellishing BGP to provide additional IDRP-like capabilities,
with ATN as potential consumer of such new features.
+ added "Acknowledgments" section (section 6).
+ added some extra hacks to document build process to warp table of
contents up to front of document.
D. Mitzel [Page 41]