rfc3002.txt

Overview of 2000 IAB Wireless Internetworking Workshop

   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.







Mitzel                       Informational                     [Page 21]

RFC 3002                 IAB Wireless Workshop             December 2000


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




Mitzel                       Informational                     [Page 22]

RFC 3002                 IAB Wireless Workshop             December 2000


   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



Mitzel                       Informational                     [Page 23]

RFC 3002                 IAB Wireless Workshop             December 2000


   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.




Mitzel                       Informational                     [Page 24]

RFC 3002                 IAB Wireless Workshop             December 2000


   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.



Mitzel                       Informational                     [Page 25]

RFC 3002                 IAB Wireless Workshop             December 2000


   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".