RFC3002 - Overview of 2000 IAB Wireless Internetworking Workshop

Network Working Group D. Mitzel
Request for Comments: 3002 Nokia
Category: Informational December 2000
Overview of 2000 IAB Wireless Internetworking Workshop
Status of this Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved.
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 evaluate methods to improve communication and
collaboration among Internet standards working groups and those of
the telephony and wireless sectors. 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
mailing list.
Table of Contents
1 IntrodUCtion . . . . . . . . . . . . . . . . . . . . 3
2 Presentation Overview . . . . . . . . . . . . . . . . 4
3 Discussion and Observations . . . . . . . . . . . . . 9
3.1 Discussion on "Walled Garden" Service Model . . . . . 9
3.2 Discussion on Mobility and Roaming . . . . . . . . . 10
3.2.1 Discussion on Mobility and Roaming Model . . . . . . 11
3.2.2 Discussion on Mobility and Roaming Protocols . . . . 11
3.2.3 Discussion on Mobility and Roaming Services . . . . . 12
3.3 Discussion on Security Model . . . . . . . . . . . . 12
3.3.1 Discussion on User Identity . . . . . . . . . . . . . 12
3.3.2 Discussion on WAP Security . . . . . . . . . . . . . 13
3.3.3 Discussion on 3G Network Security . . . . . . . . . . 13
3.4 Discussion on Transports . . . . . . . . . . . . . . 14
3.4.1 Discussion on Link Characteristics and Mobility
Effect on Transport . . . . . . . . . . . . . . . . . 14
3.4.2 Discussion on WAP Transport . . . . . . . . . . . . . 16
3.4.3 Discussion on IETF Transport Activities . . . . . . . 16
3.5 Discussion on Aeronautical Telecommunication Network
(ATN) Routing Policy. . . . . . . . . . . . . . . . . 17
3.6 Discussion on QoS Services . . . . . . . . . . . . . 18
3.6.1 Discussion on "Last Leg" QoS . . . . . . . . . . . . 18
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.2 Recommendations for Dealing with "Walled Garden"
Model . . . . . . . . . . . . . . . . . . . . . . . . 26
4.3 Recommendations on IPv4 and IPv6 Scaling . . . . . . 27
4.4 Recommendations on IPv4 and IPv6 Mobility . . . . . . 28
4.5 Recommendations on TCP and Transport Protocols . . . 29
4.6 Recommendations on Routing . . . . . . . . . . . . . 31
4.7 Recommendations on Mobile Host QoS Support . . . . . 32
4.8 Recommendations on Application Mobility . . . . . . . 33
4.9 Recommendations on TCP/IP Performance Characterization
in WAP-like Environment . . . . . . . . . . . . . . . 33
4.10 Recommendations on Protocol Encoding . . . . . . . . 33
4.11 Recommendations on Inter-Domain AAA Services . . . . 34
4.12 Recommendations on Bluetooth . . . . . . . . . . . . 34
4.13 Recommendations on Proxy Architecture . . . . . . . . 34
4.14 Recommendations on Justifying IPv6-based Solutions for
Mobile / Wireless Internet . . . . . . . . . . . . . 35
5 Security Considerations . . . . . . . . . . . . . . . 35
6 Acknowledgments . . . . . . . . . . . . . . . . . . . 35
7 Bibliography . . . . . . . . . . . . . . . . . . . . 36
A Participants . . . . . . . . . . . . . . . . . . . . 41
B Author"s Address . . . . . . . . . . . . . . . . . . 41
Full Copyright Statement . . . . . . . . . . . . . . 42
1 Introduction
Wireless technology, including wireless LANs, data transfer over
cellular radio (GSM, 3GPP, etc), and mobile operations from aircraft
and near earth spacecraft are becoming increasingly important. Some
market projections 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 imperfections, unnecessary complexities, the chattiness of
the application protocols, and network layer addressing issues.
Unfortunately, this creates some serious issues at the wired/wireless
demarcation: end to end operation is sacrificed, security is
compromised, and automated content modification 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
+ 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 participants. Finally, section 5
highlights references to security considerations discussed, appendix
A lists contact information of workshop participants, 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?
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/
Cellular_JSo.PDF,
http://www.iab.org/IAB-wireless-workshop/talks/
Cellular_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
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
_Presentation.PDF,
http://www.iab.org/IAB-wireless-workshop/talks/MWIF_TC
_Presentation.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
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-
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
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 linearly 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
difference 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 service "content". This style
of service model appears to have been inherited from the classic
telephony provider model. The term "walled garden" was coined to
describe the resulting captive customer economic and service 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
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 indicated 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 administration. These
simplification can eliminate roadblocks to service deployment 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 garden" Internet-based services will operate somewhat like
current intranet services. Also, mechanisms should be investigated
to simplify interoperation 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
cellular 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 Internet-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
mobility and roaming needs to be supported. Current usage in the
Internet is dominated by the mode where a user performs some actions
at one location, then shuts down and moves, followed by restart at a
new location.
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
consensus 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
provided 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 architecture relying on telephone system for all
mobility support, hiding roaming 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 forwarding path. There appears significant work
remaining to reach convergence on opinions, and additional
investigation to support roaming across cellular, WLAN, and IP
boundaries.
3.2.3 Discussion on Mobility and Roaming Services
3G.IP mobility model is primarily focused on providing ubiquitous
service 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 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 typically driven by market demand, which can lead to
"chicken and egg" problem. 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 protocols 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
protocol 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 identification 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 transfer 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.
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
optimized 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 protocols, 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".
Similar 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 service 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
exposure 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 protocols and obscurity.
Completing support for the security requirements of the 3GPP/3GPP2
network seems to require resolving issues in two primary areas, AAA
services and mobile IP. AAA is required for authentication,
authorization, and billing. Remaining issues center around cross
domain AAA, authentication using PKI, and there was considerable
aversion to use of IPsec and IKE protocols due to perceived overhead
and delay. Mobile IP issues 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 standardization
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
Transport
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. However, the amount
of discussion and suggestions on TCP performance optimizations 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-
congestive 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 experience dropouts. In
this situation any active TCP sessions will commence 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)
system to signal to the TCP session its current operating mode.
Developing a robust form of such a signaling mechanism, and
integrating these signals 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 considerable 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 problems 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 regardport (see discussion below in section
3.4.3).
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 segment
loss or duplication during handoff? Work on D-SACK [25] may alleviate
these worries, detecting reordering and allowing for adaptive DUP-ACK
threshold. Finally, there was suggestion it might be appropriate to
adapt (i.e., 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 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 retransmission timers and lack of congestion control. This
gave rise to suggestions that the IETF write up more details on the
history and tradeoffs in transport design to aid others doing
transport design work, and secondly that the IETF advocate that the
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 result 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 Service (DoS) attacks. It was also encouraged that the
WAPF members participate in the IETF directly contribute requirements
and remain abreast of current efforts on evolving TCP operation and
introduction of new transport (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,
Forward Error Correction (FEC), large windows, SACK, NewReno Fast
Recovery, ACK congestion control, segment byte counting, Explicit
Congestion Notification (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 associations 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 standardizing
congestion control algorithms, and work in the Performance
Implications of Link Characteristics (pilc) working group is
characterizing performance impacts of various link technologies and
investigating performance improvements.
This vast array of ongoing research and standards development seemed
a bit overwhelming, and there was considerable disagreement on the
performance and applicability of several TCP extensions. However,
this discussion 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 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 improvements have been
proposed and standardized to address unique characteristics 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 aircraft. 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 selection. 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 equivalent to support in BGP. Several
issues with BGP were raised for further investigation. For example,
whether BGP AS space is sufficient to accommodate 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 peerings? 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.
passenger entertainment traffic.
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
underlying 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 support 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
architecture. 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
seamless adaptation across handoffs without service disruption.
There were concerns 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 aggregate 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
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 mechanisms 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 capability 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 investigation.
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 application (layered over IP [52,19], UDP [51], and RTP
[57]) requires a minimum 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 Compression (rohc) working group. This working group has
established goals for wireless environment, to conserve radio
spectrum, to accommodate mobility, and to be robust to packet loss
both before the point where compression 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 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
overhead, 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
preferring 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 performance 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
protocols were felt to be too inefficient for adoption with very low
datarate bearer services and limited capability devices. The WAP
Wireless 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
efficient connection and capability negotiation. Similarly, the WAP
Wireless 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 discussion on usage of WWW protocols with wireless handheld
devices.
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
inefficient 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. Investigation of compact protocol encoding, capability
negotiation, and minimizing 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
architectures. 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
connections. Some types of proxy break the Internet end-to-end
communication and security models. Other proxy architectures may
limit system scalability 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)
subscribers, 600 million wired stations on the Internet, and over 600
million 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 terminals have potential to form a
significant component of the total Internet. These conclusions
seemed to form the basis for many additional recommendations to push
for adoption of IPv6 protocols in emerging (3G) markets.
In nearly all the presentations on 3G cellular network technologies
discussion 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. Arguments 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 development 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 capacity 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 features. 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
introduction. IPv6 addresses scaling requirements of wireless data
user projections 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 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 support mobility, with graceful handling of
mobile handoff, updating location information with remote peer, and
even simultaneous handoff of both endpoints. The problem with SIP
adoption seems to be its slow standardization 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
Organizations
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
standards 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
protocols. At first glance these would seem successes for adoption
of Internet technologies, however the decision to rely on IETF
standards often introduced frustrations too.
One common theme for frustration is differences in standardization
procedures. For instance, 3GPP follows a strict model of publishing
recommendations 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 "service". Wading through all the protocol
specifications, deciding on optional features and piecing together
the components to deliver a commercial 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.
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
beneficial to understand these concerns and frustrations. It seemed
clear there can be some benefits in improving communication with
other standards organizations and encouraging their participation in
IETF activities.
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 recommend 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 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
organizations is mutual education. To help in achieving this goal
recommendations were made related to documenting more of the history
behind Internet 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
models. 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
heterogeneous environment the IETF must continue to foster the
adoption of an "open model". IETF protocol design must address
seamless, secure, and scalable access.
4.2.2
Recognition that the "walled garden" model has some perceived
benefits led to recommendations to better integrate it into the
Internet architecture. 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
traditional 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 performance 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 interactions with app