As per Relevance of the word discussion, we have this rfc below:
Network Working Group D.
Request for Comments: 3002
Category: Informational December 2000
Overview of 2000 IAB Wireless Internetworking
Status of this
This memo provides information for the Internet community. It
not specify an Internet standard of any kind. Distribution of
memo is unlimited
Copyright
Copyright (C) The Internet Society (2000). All Rights Reserved
This document provides an overview of a workshop held by the
Architecture Board (IAB) on wireless internetworking. The
was hosted by Nokia in Mountain View, CA, USA on February 29
March 2, 2000. The goal of the workshop was to assess current
future uses of Internet technology in wireless environments, to
recommendations on research and standardization tasks to
acceptance of Internet network and transport protocols in
environments, and to evaluate methods to improve communication
collaboration among Internet standards working groups and those
the telephony and wireless sectors. This report summarizes
conclusions and recommendations of the IAB on behalf of the
community
Comments should be submitted to the IAB-Wireless-Workshop@ietf.
mailing list
Table of
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
Mitzel Informational [Page 1]
RFC 3002 IAB Wireless Workshop December 2000
3.3.3 Discussion on 3G Network Security . . . . . . . . . . 13
3.4 Discussion on Transports . . . . . . . . . . . . . . 14
3.4.1 Discussion on Link Characteristics and
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
(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
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
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
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
Mitzel Informational [Page 2]
RFC 3002 IAB Wireless Workshop December 2000
1
Wireless technology, including wireless LANs, data transfer
cellular radio (GSM, 3GPP, etc), and mobile operations from
and near earth spacecraft are becoming increasingly important.
market projections suggest that a mobile Internet in parallel with
augmenting the wired Internet may be comparable in size to the
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,
protocol imperfections, unnecessary complexities, the chattiness
the application protocols, and network layer addressing issues
Unfortunately, this creates some serious issues at the wired/
demarcation: end to end operation is sacrificed, security
compromised, and automated content modification in some form
necessary. The IAB considers these to be serious fundamental issues
which will in time be a serious impediment to the usability of
combined Internet if not addressed
The Internet Architecture Board (IAB), on February 29 thru March 2,
2000, held an invitational workshop on wireless internetworking.
goal of the workshop was to assess current and future uses
Internet technology in wireless environments, to make
on research and standardization tasks to improve acceptance
Internet network and transport protocols in wireless environments
and to evaluate methods to improve communication and
among Internet standards working groups and those of the
and wireless sectors
The following topics were defined for discussion
+ Local area wireless
+ Cellular wireless
+ Wireless Application Protocol (WAP
+ Near-space and aviation wireless
+ Voice over IP (VoIP) over wireless
+ Security over wireless
+ Transport and QoS over wireless
+ Use of WWW protocols over wireless and small screen
Mitzel Informational [Page 3]
RFC 3002 IAB Wireless Workshop December 2000
+ Addressing requirements for wireless
+ Compression and bit error requirements for wireless
The fundamental question addressed in these discussion is "what
the issues, and what really needs to be done to unify the
below the application layer." Applications will also need to
addressed, but were perceived to be more than could be
discussed in a three-day workshop, and probably require
expertise
Section 2 presents a concise overview of the individual
made during the workshop. References to more extensive materials
provided. Details on major discussion topics are provided in
3. Section 4 presents the recommendations made to
operators, IRTF, and IETF on the architectural roadmap for the
few years. It should be noted that not all participants agreed
all of the statements, and it was not clear whether anyone
with all of them. However, the recommendations made are based
strong consensus among the participants. Finally, section 5
highlights references to security considerations discussed,
A lists contact information of workshop participants, and appendix
lists the author contact information
2 Presentation
Title: Overview of Wireless IP Devices (Network Implications...)
Presenter: Heikki
Reference
http://www.iab.org/IAB-wireless-workshop/talks/hh-IABpub.PDF
http://www.iab.org/IAB-wireless-workshop/talks/hh-IABpub.
Overview
Title: Overview of IEEE 802.11 Wireless LAN's & Issues Running
over IEEE 802.11?
Presenter: Juha Ala-
Reference
http://www.iab.org/IAB-wireless-work
shop/talks/IEEE80211_IP.
Overview
Mitzel Informational [Page 4]
RFC 3002 IAB Wireless Workshop December 2000
Title: Overview of Bluetooth Wireless & Issues Running IP
Bluetooth
Presenter: Pravin
Reference
http://www.iab.org/IAB-wireless-workshop/talks/BT
overview.PDF
http://www.iab.org/IAB-wireless-workshop/talks/BT
overview.
Overview
Title: Overview of Cellular Data Systems & Approaches to more
centric Cellular Data
Presenter: Jonne
Reference
http://www.iab.org/IAB-wireless-workshop/talks
Cellular_JSo.PDF
http://www.iab.org/IAB-wireless-workshop/talks
Cellular_JSo.
Overview
Title: IP Packet Data Service over IS-95
Presenter: Phil
Reference
http://www.iab.org/IAB-wireless-workshop/talks/karn/index.
Overview
Title: Wireless Internet
Presenter: Chih-Lin
Reference
http://www.iab.org/IAB-wireless-workshop/talks/IAB000229.PDF
http://www.iab.org/IAB-wireless-workshop/talks/IAB000229.
Overview
Title: Mobile IP in Cellular Data
Presenter: Charlie
Mitzel Informational [Page 5]
RFC 3002 IAB Wireless Workshop December 2000
Reference
http://www.iab.org/IAB-wireless-workshop/talks/WLIP99.PDF
http://www.iab.org/IAB-wireless-workshop/talks/WLIP99.
Overview
Title: Overview of
Presenter: Alastair
Reference
http://www.iab.org/IAB-wireless-workshop/talks/iab-wap-1.
Overview
Title: Mobile Wireless Internet Forum (MWIF
Presenter: Alastair
Reference
http://www.iab.org/IAB-wireless-workshop/talks/MWIF_
_Presentation.PDF
http://www.iab.org/IAB-wireless-workshop/talks/MWIF_
_Presentation.
Overview
Title: Some WAP
Presenter: Jerry
Reference
http://www.iab.org/IAB-wireless-workshop/talks/waphist.PDF
http://www.iab.org/IAB-wireless-workshop/talks/waphist.
Overview
Title: Near-space Wireless
Presenter: Mark
Reference
http://www.iab.org/IAB-wireless-workshop/talks/allman-iab
wireless.pdf
http://www.iab.org/IAB-wireless-workshop/talks/allman-iab
wireless.
Overview
Mitzel Informational [Page 6]
RFC 3002 IAB Wireless Workshop December 2000
Title: Air Traffic / Aviation
Presenter: Chris
Reference
http://www.iab.org/IAB-wireless-workshop/talks/wargo-talk.PDF
http://www.iab.org/IAB-wireless-workshop/talks/wargo-talk.
Overview
Title: VoIP over
Presenter: Christian
Reference
http://www.iab.org/IAB-wireless-workshop/talks/iab-wless
voip.PDF
http://www.iab.org/IAB-wireless-workshop/talks/iab-wless
voip.
Overview
Title: Security Issues in Wireless Networks and Mobile
Presenter: N.
Reference
http://www.iab.org/IAB-wireless-workshop/talks/mobile-secu
rity.PDF
http://www.iab.org/IAB-wireless-workshop/talks/mobile-secu
rity.
Overview
Title: Security for Mobile IP in 3G
Presenter: Pat
Reference
http://www.iab.org/IAB-wireless-workshop/talks/mip-sec-3g.PDF
http://www.iab.org/IAB-wireless-workshop/talks/mip-sec-3g.
Overview
Title: On Inter-layer Assumptions (A View from the Transport Area
Presenter: Mark
Mitzel Informational [Page 7]
RFC 3002 IAB Wireless Workshop December 2000
Reference
http://www.iab.org/IAB-wireless-workshop/talks/handley
wireless.pdf
http://www.iab.org/IAB-wireless-workshop/talks/handley-wire
less.
Overview
Title: Does current Internet Transport work over Wireless
Presenter: Sally
Reference
http://www.iab.org/IAB-wireless-workshop/talks/IAB-wireless
Mar00.pdf
http://www.iab.org/IAB-wireless-workshop/talks/IAB-wireless
Mar00.
Overview
Title: QOS for Wireless (DiffServ, IntServ, other?)
Presenter: Lixia
Reference
http://www.iab.org/IAB-wireless-workshop/talks/zhang-feb
IAB.PDF
http://www.iab.org/IAB-wireless-workshop/talks/zhang-feb
IAB.
Overview
Title: Do current WWW Protocols work over Wireless and
Screen Devices
Presenter: Gabriel
Reference
http://www.iab.org/IAB-wireless-workshop/talks/wireless
www.PDF
http://www.iab.org/IAB-wireless-workshop/talks/wireless
www.
Overview
Title: Compression & Bit Error Requirements for
Presenter: Mikael
Mitzel Informational [Page 8]
RFC 3002 IAB Wireless Workshop December 2000
Reference
http://www.iab.org/IAB-wireless-workshop/talks/iab-hc.PDF
http://www.iab.org/IAB-wireless-workshop/talks/iab-hc.
Overview
Title: Addressing Requirements for Wireless Devices & IPv
Presenter: Bob
Reference
http://www.iab.org/IAB-wireless-workshop/talks/Addressing
IPv6.PDF
http://www.iab.org/IAB-wireless-workshop/talks/Addressing
IPv6.
Overview
3 Discussion and
During the workshop presentations a number of issues were
and observations made. The following sections 3.1 -- 3.12
these discussion and observations. Rather than organizing
material linearly by presentation, it is grouped according to
"themes" and issues
3.1 Discussion on "Walled Garden" Service
Presentations from members involved in the cellular wireless (3GPP
3G.IP, MWIF) and WAP environments quickly illustrated a
difference in protocol specification and service models from
typically assumed by the Internet community. These communities
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
possible) control over the entire service, including user
device, transmission facilities, and service "content". This
of service model appears to have been inherited from the
telephony provider model. The term "walled garden" was coined
describe the resulting captive customer economic and service model
That is, the user is constrained within the limits of the
provided by the carrier with limited ability to extend features
access services outside the provider. The "walled garden
service model is in stark contrast to the "open" service assumed
the Internet. The application, access device, and service
may each be controlled by a different entity, and the
provider is typically viewed as little more than a "bit pipe".
Mitzel Informational [Page 9]
RFC 3002 IAB Wireless Workshop December 2000
Additionally, specification typically define a standalone protocol
application rather than the set of features and interoperation
other components required to deploy a commercial service
Some discussion focused on whether cellular carriers could
persuaded to transition toward the Internet "open" service model
Responses indicated that there was little hope of this as
will always fight being reduced to a "bit pipe", fearing they
sustain sufficient revenues without the value added services.
additional point raised was that the closed model of the "
garden" simplifies a number of issues, such as security
authorization, and billing when the entire network is
secured and controlled under a single administration.
simplification can eliminate roadblocks to service deployment
scalable, interdomain solutions are available
Even though there seems little hope of evolving carriers away
the "walled garden" service in the short term, there was
value in recognizing its presence. This led to observations
"walled garden" Internet-based services will operate somewhat
current intranet services. Also, mechanisms should be
to simplify interoperation and controlled access to the Internet
Finally, the difference between Internet protocol
contrasted to service profiles highlights some of the confusion
in the telephony environment encounter when attempting to
Internet capabilities
Much of the current work in extending Internet-based services
cellular customers has focused on data services such as email or
access. One observation on the reluctance of carriers to release
control over services was that this may be an impediment to
of Internet-based voice services. Current work on voice over
(VoIP) and call signaling (SIP [30]) loosens control over
services, much of the functionality is moved into the SIP agent
the carrier being reduced to an access provider (i.e., "bit pipe").
3.2 Discussion on Mobility and
An inherent characteristic of wireless systems is their potential
accommodating device roaming and mobility. Some discussion
on the model of mobility presented to the user. There was
considerable interest and discussion on protocols employed,
cellular telephony and/or IP-based solutions. Finally, there
some interest in exploring new services enabled by mobility
Mitzel Informational [Page 10]
RFC 3002 IAB Wireless Workshop December 2000
3.2.1 Discussion on Mobility and Roaming
There was considerable discussion and concern over what style
mobility and roaming needs to be supported. Current usage in
Internet is dominated by the mode where a user performs some
at one location, then shuts down and moves, followed by restart at
new location
3G.IP uses the term "macro mobility" to describe this mode
The discussion attempted to discern whether the current mode of
is a perceived limitation introduced by current protocols. A
consensus could not be achieved. There was agreement
introduction of this "macro mobility" roaming is a worthwhile
step. However, that was immediately followed by questions on
it is a sufficient first step, and warning not to stop at this level
There seems significant issues for continued investigation related
enabling continual usage of a device during roaming ("
mobility") and the ability to retrieve previous connections after
roaming event
3.2.2 Discussion on Mobility and Roaming
Selection between cellular and IP protocols in support of
provided another topic for significant discussion.
operators have already deployed protocols providing
support for roaming. This has led several efforts, such as 3GPP
3G.IP, toward architecture relying on telephone system for
mobility support, hiding roaming from the IP layer
Arguments for cellular-based roaming centered on concerns about
mobile IP model. There was concern that home agent and foreign
involvement in delivery might introduce bottleneck, and
perception that mobile IP handoff is too slow. A rebuttal
was that IETF mobileip working group is introducing hierarchy
route optimization to improve performance and robustness [50],
there was disagreement on the point regarding slow handoff
mobile IP
Detriments to the cellular-based roaming include the lack of
support out to the mobile device and the added tunneling
and overhead required. Additionally, roaming is less well
when traversing service provider boundaries and may involve
non-optimal forwarding path. There appears significant
remaining to reach convergence on opinions, and
investigation to support roaming across cellular, WLAN, and
boundaries
Mitzel Informational [Page 11]
RFC 3002 IAB Wireless Workshop December 2000
3.2.3 Discussion on Mobility and Roaming
3G.IP mobility model is primarily focused on providing
service across a range of access media. However, the
also highlighted a desire to develop new "location based" services
Examples presented include locating nearby services or
advertisement and solicitations from nearby business
There are several Internet protocols defined, such as anycast
[47] and SLP [28], that may aid in developing location
services. However, there was considerable frustration on the part
3G.IP in that there appears little commercial support of
protocols, and even less direction on how to assemble and
the required protocols to deploy the desired services
This exchange illustrated the disconnect between
Internet standards and telephony service profiles. First, in
Internet many protocols are defined but many are optional.
support is typically driven by market demand, which can lead
"chicken and egg" problem. Secondly, individual protocols
applications are developed rather than complete profile to compose
commercial service. For this service, evaluating the usage
scalability of service discovery protocols appears to be an area
for further investigation
3.3 Discussion on Security
Mobility and wireless environments introduce many complexities
potential attacks to user authentication and privacy. In addition
the discussion presented below, there was an overriding
made regarding the methodology that must be followed for all
protocol development. It was felt quite strongly that the
chance for success is that the definition be done in a public forum
allowing full disclosure of all algorithms and thorough review
security experts. Stated an alternate way, defining protocols in
closed forum relying on cellphone manufacturers, or other non-
on IP security, is very likely to create security exposures
3.3.1 Discussion on User
Storage of user identity can have significant effect on device
and device portability. Discussion focused on whether
should be tied to the mobile device or a transferable SIM card
Fixing identification with the device may simplify manufacture
provide some tamper resistance, however it makes it very difficult
deploy a public device taking on the identity of the user.
alternative also affect transfer of identity and configuration
on device replacement or upgrade
Mitzel Informational [Page 12]
RFC 3002 IAB Wireless Workshop December 2000
A related topic revolves around the user desire to employ a
device but to take on a different identity and privilege based on
usage at hand (e.g., to gain corporate access, home access,
Internet access). The ability and ease of assuming these
identities may be highly dependent on the model of
integration, as discussed above. Discussion highlighted
pitfalls based on tieing of device and user identities. IPsec use
device IP address inhibits roaming capabilities as the address
change based on location, and precludes distinguishing identity
capabilities for current usage. IPsec requires additional work
accommodate this added flexibility
A final topic of discussion on user identity establishment
whether possession of the device is sufficient, or whether the
should be required to authenticate to the device. In the real
the first alternative is exemplified by the credit card model,
the second is more analogous to the ATM card where the user must
provide a PIN code. Both models seem useful in the real world,
it's likely both will have uses in wireless networking
3.3.2 Discussion on WAP
WAP wireless transport security (WTLS) is based on TLS [20],
optimized handshake to allow frequent key exchange. The
service employs a "vertical" integration model, with
components throughout the network stack. Some argued that this
the wrong model. A better approach may have been a security
with well defined interfaces. This could allow for later
among different protocols, driven by market, applications, and
capabilities
Additional statements argued that the WAP security model
dangers from optimizing for a limited usage domain ("walled garden").
Content provider systems requiring security (e.g., banks) must
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
The existing GSM/GPRS model uses long term shared secrets (
in SIM card) with one-way authentication to the network, and
privacy only provided on the access link. This is an example
the "walled garden" service model has an advantage. Complete
over the service access devices and network greatly reduces the
of security concerns and potential attacks
Mitzel Informational [Page 13]
RFC 3002 IAB Wireless Workshop December 2000
Future 3GPP and 3GPP2 plan to push IP all the way out to the
device. An observation is that this results in more potential
exposure of signaling and control plane to attacks. Desire is
perform mutual authentication and securing of the network. This is
difficult problem with additional issues remaining to be solved
however the statement was made that relying on IP and open
is more likely to produce a provably secure network than
reliance on SS7 protocols and obscurity
Completing support for the security requirements of the 3GPP/3GPP
network seems to require resolving issues in two primary areas,
services and mobile IP. AAA is required for authentication
authorization, and billing. Remaining issues center around
domain AAA, authentication using PKI, and there was
aversion to use of IPsec and IKE protocols due to perceived
and delay. Mobile IP issues revolve around solutions to reduce
security associations required between mobile node and home agent
mobile node and foreign agent, and the home and foreign agent.
interim solution being investigated involves use of a RADIUS
[56]; however, there are concerns with repeated dynamic
generation on each handoff or hiding some details of handoffs,
may violate assumptions in mobile IP protocol [48].
requirements and addressing all of these open issues appears to be
excellent opportunity for mutual cooperation on open
and review
3.4 Discussion on
Discussion on transport protocols touched on a broad range of issues
Concerns ranged from the effects of wireless link characteristics
mobility effect on TCP, to development of new transport
such as WAP Wireless Transaction Protocol (WTP). In addition,
significant amount of time was spent reviewing ongoing efforts
the IETF on TCP transport enhancements and investigation of
transports
3.4.1 Discussion on Link Characteristics and Mobility Effect
TCP makes assumptions on loss as congestion indication.
statement was made that TCP was designed for links with about 1%
corruption loss, and provided that constraint is met then TCP
function properly. Presentation on IS-95 CDMA-based data
showed that it conditions line to provide 1--2% error rate
little correlation between loss. Similar conditioning and
Error Correction (FEC) mechanisms may be appropriate for
wireless and satellite systems [4]. This may not be true for
wireless media, but it was interesting in the fact that it
Mitzel Informational [Page 14]
RFC 3002 IAB Wireless Workshop December 2000
TCP should work properly on many wireless media. However, the
of discussion and suggestions on TCP performance optimizations
that there can be a considerable gap between merely working
working well
One issue raised several times was related to the effects of non
congestive loss on TCP performance. In the wireless
non-congestive loss may be more prevalent due to corruption
(especially if the wireless link cannot be conditioned to
control error rate) or an effect of mobility (e.g., temporary
while roaming through an area of poor coverage). These losses
have great detrimental effect on TCP performance, reducing
transmission window and halving the congestion window size. Much
the discussion focused on proposing mechanisms to explicitly
a non-congestive loss to the TCP source. Suggestions included
Non-Congestive Loss Indication (NCLI) sent for instance when
corruption loss is detected, or sending a Source Encourage (SE)
stimulate source transmission at the end of an outage. In
to data corruption, wireless links can also experience dropouts.
this situation any active TCP sessions will commence
retransmissions, using an exponentially increasing back-off
between each attempt. When the link becomes available it may be
seconds before the TCP sessions resume transmission. Mechanisms
alleviate this problem, including packet caching and
retransmission were discussed. The more generic form of all of
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,
integrating these signals into the end-to-end TCP control loop
present opportunities to improve TCP transport efficiency
wireless environments
TCP improvements have been incorporated to support "long"
(i.e., those with large delay and bandwidth characteristics) [36],
however considerable expertise may still be required to tune
buffers for maximum performance. Some work has been done on auto
tuning buffers, which shows promise [58]. An additional problem
large windows and auto-tuning is the added header overheads.
may exasperate the problems of running TCP over low bandwidth links
Suggestions included to explore dynamic negotiation of large
extensions in the middle of a connection to alleviate these issues
A final issue raised with regardport (see discussion below in
3.4.3).
There was also concern regarding mobility effects on TCP performance
TCP has implicit assumptions on bounding propagation delay. If
exceeds the smoothed round trip time plus four times the round
variance then the segment is considered lost, triggering the
Mitzel Informational [Page 15]
RFC 3002 IAB Wireless Workshop December 2000
backoff procedures. Could these assumptions be violated by
loss or duplication during handoff? Work on D-SACK [25] may
these worries, detecting reordering and allowing for adaptive DUP-
threshold. Finally, there was suggestion it might be appropriate
adapt (i.e., trigger slow start) immediately after mobile handoff
the assumption that path characteristics may differ
3.4.2. Discussion on WAP
WAPF considered TCP connection setup and teardown too expensive
terms of bit overhead and latency when required for
transaction. WAPF developed the Wireless Transaction Protocol (WTP),
with some inspiration from T/TCP [12]. WTP offers several classes
service ranging from unconfirmed request to single request
single reply transaction. Data is carried in the first packet
3-way handshake eliminated to reduce latencies. In
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
there was concern that it may miss critical or subtle
issues learned through years of Internet research and
experience. One potential area for disaster appeared to be the
of fixed retransmission timers and lack of congestion control.
gave rise to suggestions that the IETF write up more details on
history and tradeoffs in transport design to aid others
transport design work, and secondly that the IETF advocate that
congestion control is not optional when using rate adaptive
protocols
The remaining discussion on WAP transport primarily focused on
to share information. It was suggested that any result from
study of TCP shortcomings that led to its rejection might be
for IETF review as inputs for TCP modifications. Similar
were raised on study of T/TCP shortcomings and its potential
to Denial of Service (DoS) attacks. It was also encouraged that
WAPF members participate in the IETF directly contribute
and remain abreast of current efforts on evolving TCP operation
introduction of new transport (see discussion below in
3.4.3.).
3.4.3 Discussion on IETF Transport
Discussion on transport work in the IETF presented a large array
activities. Recent work on transport improvement includes path MTU
Forward Error Correction (FEC), large windows, SACK, NewReno
Recovery, ACK congestion control, segment byte counting,
Congestion Notification (ECN), larger initial transmit windows,
Mitzel Informational [Page 16]
RFC 3002 IAB Wireless Workshop December 2000
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
Transport (sigtran) working group and TCP-Friendly Rate
(TFRC) [1] by researchers at ACIRI. SCTP provides a reliable UDP
like protocol supporting persistent associations and in-
delivery with congestion control. TFRC is targeted at unreliable
unicast streaming media. Finally, work in the IETF End-
Congestion Management (ecm) working group is looking at
congestion control algorithms, and work in the
Implications of Link Characteristics (pilc) working group
characterizing performance impacts of various link technologies
investigating performance improvements
This vast array of ongoing research and standards development
a bit overwhelming, and there was considerable disagreement on
performance and applicability of several TCP extensions. However
this discussion did raise a couple of key points. First,
work within the Internet community is not stagnant, there is
significant amount of interest and activity in improvement
existing protocols and exploration of new protocols. Secondly,
work with researchers in satellite networking has demonstrated
tremendous success possible in close collaboration. The
networking community was dissatisfied with initial TCP performance
long delay links. Through submission of requirements
collaborative investigation a broad range of improvements have
proposed and standardized to address unique characteristics of
environment. This should hopefully set a very positive precedent
encourage those in the wireless sector to pursue
collaboration in adoption of Internet protocols to their environment
3.5 Discussion on Aeronautical Telecommunication Network (ATN)
The Aeronautical Telecommunication Network (ATN) has goals to
and standardize communications in the aviation industry. This
across air traffic management and control, navigation
surveillance, all the way up to passenger telephone service
entertainment. This also involves integration of both fixed
segments and mobile aircraft. Supporting the ATN architecture
Internet protocols may introduce additional requirements on
routing infrastructure
Current ATN views each aircraft as an autonomous network (AS)
changing point of attachment as it "roams" through
airspace. Addressing information associated with the aircraft
fixed, which makes route aggregation difficult since they're
related to topology, and also increases the frequency of updates
Additionally, the aircraft may be multiply attached (within
Mitzel Informational [Page 17]
RFC 3002 IAB Wireless Workshop December 2000
of multiple ground and space-based access networks),
routing policy support for path selection. Finally, QoS
selection capabilities may be beneficial to arbitrate shared
or partition real-time control traffic from other data traffic
Initial prototype of ATN capabilities have been based on ISO
[33] path selection and QoS routing policy. There was
discussion whether IDRP could be adopted for use in an
environment. There was quick agreement that the preferred
within the IETF would be to advance BGP4++ [8,54] as an IDRP-
replacement. This transitioned discussion to evaluation of ATN
of IDRP features and their equivalent to support in BGP.
issues with BGP were raised for further investigation. For example
whether BGP AS space is sufficient to accommodate each aircraft as
AS? Also issues with mobility support; can BGP provide
dynamically changing peering as point of attachment changes,
alternative path selection policies based on current peerings?
significant amount of additional investigation is required to
assess ATN usage of IDRP features, especially in the QoS area.
could lead to additional BGP requirements, for instance to
different prioritization or path selection for aircraft control vs
passenger entertainment traffic
3.6 Discussion on QoS
Enabling support for voice and other realtime services along
data capabilities requires Quality of Service (QoS) features
arbitrate access to the limited transmission resources in
environment. The wireless and mobile environment requires
support for the last leg between the mobile device and network
point, accommodating roaming and unique characteristics of
wireless link
In addition to the discussion presented below, it was felt
strongly that it is critical any QoS facility be provided as
underlying service independent of payload type. That is,
should be no built in knowledge of voice or other
semantics. This results in a feature that can be leveraged
easily extended to support new applications
3.6.1 Discussion on "Last Leg"
Discussion on voice over IP (VoIP) emphasized that (wireless)
link is typically the most constrained resource, and while
access (CSMA) provides good utilization for data it is not ideal
voice. Two models were identified as potential solution in
architecture. The first is to have the wireless device
signal the local access router. A second alternative is to have
Mitzel Informational [Page 18]
RFC 3002 IAB Wireless Workshop December 2000
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
of mobility and roaming handoffs. This appears a key component
solve for success in VoIP adoption
Work within the IEEE 802.11 WLAN group identified
requirements for QoS support. That group is investigating a
employing two transmission queues, one for realtime and one
best-effort traffic. Additional plans include mapping between
DiffServ markings [14,46] and IEEE 802 priorities
The statement was also made that QoS over the wireless link is
the fundamental problem, rather it is handling mobility aspects
seamless adaptation across handoffs without service disruption
There were concerns about mechanisms establishing per-flow
(RSVP [13]). Issues include scaling of state, and signaling
and setup delays on roaming events. DiffServ [9] approach
allocating QoS for aggregate traffic class, which simplifies roaming
However, DiffServ requires measurement and allocation adjustment
time, and policing to limit amount of QoS traffic injected
3.6.2 Discussion on Path QoS
The HDR high speed wireless packet data system under development
Qualcomm highlights unique characteristics of some wireless media
This system provides users a channel rate between 38.4Kb/s
2.4Mb/s, with throughput dependent on channel loading and
from network access point. This gave rise to considerable
on whether it might be possible to discover and provide feedback
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
is currently available. Additionally, it was argued that this is
accord with the current Internet stack model, which does not
any mechanisms to expose this type of information. Counter
stated that there are growing demands in Internet QoS working
requesting exposure of this type of information via
APIs. Members working on GPRS protocols also indicated
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
of how a server application might find out the capabilities of
receiver. This could allow for application adaptation to
device and path characteristics. One suggestion proposed use of
payload, which is able to transport QoS information. A
Mitzel Informational [Page 19]
RFC 3002 IAB Wireless Workshop December 2000
alternative is to push capability exchange and negotiation to
application layer. Discussion on this topic was brief,
application issues were deemed outside the workshop charter,
this also seems an area open for future investigation
3.7 Discussion on Header
A critical deterrent to Internet protocol adoption in the
band-width constrained wireless cellular environment is the
overhead of the protocol encoding. Examples presented
how a voice application (layered over IP [52,19], UDP [51], and
[57]) requires a minimum of 40 bytes of headers for IPv4 or 60
for IPv6 before any application payload (e.g., 24 byte voice sample).
This overhead was also presented as a contributing factor for
creation of WAP Wireless Datagram Protocol (WDP) rather than IP
very low datarate bearers
Discussion on header compression techniques to alleviate
concerns focused on work being performed within the IETF
Header Compression (rohc) working group. This working group
established goals for wireless environment, to conserve
spectrum, to accommodate mobility, and to be robust to packet
both before the point where compression is applied and
compressor and decompressor. Additional requirements
were that the technique be transparent, does not introduce
errors, and that it is compatible with common protocol
(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
future. It was reported that these encodings have a minimum
of 1 byte and result in average overhead of less than 2 bytes for
RTP/UDP/IP packet. There is some extra overhead required
transport checksum is required and some issues still to be
related to interoperation with encryption and tunneling
A detriment to IPv6 adoption often cited is its additional
overhead, primarily attributed to its larger address size.
secondary observation made was that it's believed that IPv
accommodates greater header compression than IPv4. This
attributed to the elimination of the checksum and
fields from the header
Discussion on use of WWW protocols over wireless highlighted
encodings as another potential detriment to their adoption. A
of alternatives were mentioned for investigation, including use of
"deflate" Content-Encoding, using compression with TLS [20],
Mitzel Informational [Page 20]
RFC 3002 IAB Wireless Workshop December 2000
Bellovin's TCP filters. Observation was made that it could
beneficial to investigate more compact alternative encoding of
WWW protocols
3.8 Discussion on Applications
IETF protocol developments have traditionally taken the approach
preferring simple encode/decode and word alignment at the cost
some extra bit transmissions. It was stated that optimizing
encoding for bit savings often leads to shortcomings or
on protocol evolution. However, it was also argued that
where physical limitations have an effect on transmission
and system performance may present exceptions where
encodings are beneficial. Cellular wireless and near-space
may fall into this category
The WAP protocols exhibit several examples where existing
protocols were felt to be too inefficient for adoption with very
datarate bearer services and limited capability devices. The
Wireless Session Protocol (WSP) is based on HTTPv1.1 [23],
WSP incorporates several changes to address perceived inefficiencies
WSP uses a more compact binary header encoding and optimizations
efficient connection and capability negotiation. Similarly, the
Wireless Application Environment (WAE) uses tokenized WML and a tag
based browser environment for more efficient operation
Additional requests for more efficient and compact
encodings, and especially improved capability negotiation were
during discussion on usage of WWW protocols with wireless
devices
Finally, work within the near-space satellite environment has
out other physical limitations that can affect performance. In
case the long propagation delays can make "chatty" protocols
inefficient and unbearable for interactive use. This
could benefit from protocols that support some form of "pipelining
operation
There seemed broad agreement that many of these
represent valid reasons to pursue optimization of
operations. Investigation of compact protocol encoding,
negotiation, and minimizing or overlapping round trips to complete
transaction could all lead to improved application performance
a wide range of environments
Mitzel Informational [Page 21]
RFC 3002 IAB Wireless Workshop December 2000
3.9 Discussion on Proxy
Proxy agents are present in a number of the wireless and
architectures. They're often required to gateway
communication domains; terminate tunnel and translate
telephony system and Internet protocols (GPRS), or to escape
"walled garden" (WAP). In conjunction with limited
handheld devices a proxy might be deployed to offload
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
protocol deployment limitations (e.g., NAT with limited IPv
addresses).
The discussion on proxy agents primarily recognized that there are
range of proxy agent types. Proxies may operate by intercepting
interpreting protocol packets, or by hijacking or
connections. Some types of proxy break the Internet end-to-
communication and security models. Other proxy architectures
limit system scalability due to state or performance constraints
There was some desire to conduct further study of proxy agent
to evaluate their effect on system operation
3.10 Discussion on Adoption of IPv
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.
up front there was caution about these projections, especially
wireless data since it is highly speculative with little history
Secondly, there was some doubt regarding potential for
revenues from user base over 1 billion subscribers; this may
pushing the limits of world population with sufficient
income to afford these devices. However, there was broad
that cellular and Internet services are going to continue
growth and that wireless data terminals have potential to form
significant component of the total Internet. These
seemed to form the basis for many additional recommendations to
for adoption of IPv6 protocols in emerging (3G) markets
In nearly all the presentations on 3G cellular network
discussion on scaling to support the projected large number
wireless data users resulted in strong advocacy by the
representatives for adoption of IPv6 protocols. There were
positive signs that groups have begun investigation into IPv6.
example, 3GPP has already defined IPv6 as an option in their 1998
1999 specifications (release R98 and R99), and are
Mitzel Informational [Page 22]
RFC 3002 IAB Wireless Workshop December 2000
specifying IPv6 as mandatory in the release 2000. The MWIF effort
also cognizant of IPv4 and IPv6 issues and is currently
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
IPv6 adoption in any of the 3G standards efforts. There
considerable feedback that the telephony carriers perceive IPv6
more difficult to deploy, results in higher infrastructure
expenses, and adds difficulty in interoperation and gatewaying to
current (IPv4) Internet. Arguments for sticking with IPv4
came down to the abundance and lower pricing of IPv4-based products
and secondary argument of risk aversion; there is currently
IPv6 deployment or operational experience and expertise, and
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
and processing overhead and its effect on small, limited
devices. This was primarily directed at IPv6 requirement for
implementation to claim conformance. Arguments that
increase in device capacity will obviate these concerns
rejected. It was stated that power constraints on these low-
devices will continue to force concerns on memory and
overhead, and impact introduction of other features. There was
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 IPv
introduction. IPv6 addresses scaling requirements of wireless
user projections and eliminates continued cobbling of
employing (IPv4) private address space and NAT. This appears an
for IAB and Internet community to take a strong stance
adoption of IPv6 as the various 3G forums wrestle with
recommendations
3.11 Discussion on
Discussion on signaling focused on call setup and control functions
and the effects of mobility. The 3G.IP group has
standardizing on either H.323 [32] or SIP [30]. Currently
seems to be split between the protocols, and neither seemed
without support for mobility. During discussion on VoIP it
presented that SIP does support mobility, with graceful handling
mobile handoff, updating location information with remote peer,
even simultaneous handoff of both endpoints. The problem with
adoption seems to be its slow standardization brought about
Mitzel Informational [Page 23]
RFC 3002 IAB Wireless Workshop December 2000
focusing on the harder multicast model rather than
definition of a unicast "profile". There seems great need for
to expedite finalization of SIP, however some argued at this
it's likely many products will need to develop support for both
and H.323, and for their interoperation
A short discussion was also raised on whether it is the correct
to incorporate the additional protocol mechanisms to
mobility into the SIP signaling. An alternative model might be
build on top of the existing mobile IP handoff facilities. There
no conclusion reached, however it seemed an area for
investigation
3.12 Discussion on Interactions Between IETF and Other 