idnits 2.17.1 draft-iab-wirelessws-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 2000) is 8655 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '30' on line 1719 looks like a reference -- Missing reference section? '50' on line 1791 looks like a reference -- Missing reference section? '47' on line 1781 looks like a reference -- Missing reference section? '28' on line 1713 looks like a reference -- Missing reference section? '20' on line 1685 looks like a reference -- Missing reference section? '56' on line 1811 looks like a reference -- Missing reference section? '48' on line 1784 looks like a reference -- Missing reference section? '4' on line 1632 looks like a reference -- Missing reference section? '36' on line 1742 looks like a reference -- Missing reference section? '58' on line 1818 looks like a reference -- Missing reference section? '41' on line 1759 looks like a reference -- Missing reference section? '2' on line 1626 looks like a reference -- Missing reference section? '25' on line 1701 looks like a reference -- Missing reference section? '12' on line 1660 looks like a reference -- Missing reference section? '3' on line 1629 looks like a reference -- Missing reference section? '5' on line 1636 looks like a reference -- Missing reference section? '6' on line 1639 looks like a reference -- Missing reference section? '24' on line 1697 looks like a reference -- Missing reference section? '43' on line 1767 looks like a reference -- Missing reference section? '53' on line 1801 looks like a reference -- Missing reference section? '63' on line 1835 looks like a reference -- Missing reference section? '61' on line 1829 looks like a reference -- Missing reference section? '1' on line 1624 looks like a reference -- Missing reference section? '33' on line 1730 looks like a reference -- Missing reference section? '8' on line 1646 looks like a reference -- Missing reference section? '54' on line 1805 looks like a reference -- Missing reference section? '14' on line 1667 looks like a reference -- Missing reference section? '46' on line 1777 looks like a reference -- Missing reference section? '13' on line 1663 looks like a reference -- Missing reference section? '9' on line 1650 looks like a reference -- Missing reference section? '52' on line 1798 looks like a reference -- Missing reference section? '19' on line 1682 looks like a reference -- Missing reference section? '51' on line 1795 looks like a reference -- Missing reference section? '57' on line 1815 looks like a reference -- Missing reference section? '38' on line 1748 looks like a reference -- Missing reference section? '42' on line 1763 looks like a reference -- Missing reference section? '23' on line 1694 looks like a reference -- Missing reference section? '32' on line 1726 looks like a reference -- Missing reference section? '22' on line 1691 looks like a reference -- Missing reference section? '27' on line 1709 looks like a reference -- Missing reference section? '44' on line 1771 looks like a reference -- Missing reference section? '45' on line 1774 looks like a reference -- Missing reference section? '18' on line 1679 looks like a reference -- Missing reference section? '21' on line 1688 looks like a reference -- Missing reference section? '60' on line 1825 looks like a reference -- Missing reference section? '16' on line 1673 looks like a reference -- Missing reference section? '29' on line 1716 looks like a reference -- Missing reference section? '31' on line 1722 looks like a reference -- Missing reference section? '10' on line 1653 looks like a reference -- Missing reference section? '11' on line 1656 looks like a reference -- Missing reference section? '55' on line 1808 looks like a reference -- Missing reference section? '15' on line 1670 looks like a reference -- Missing reference section? '17' on line 1676 looks like a reference -- Missing reference section? '62' on line 1832 looks like a reference -- Missing reference section? '37' on line 1745 looks like a reference -- Missing reference section? '26' on line 1705 looks like a reference -- Missing reference section? '49' on line 1787 looks like a reference -- Missing reference section? '34' on line 1734 looks like a reference -- Missing reference section? '35' on line 1738 looks like a reference -- Missing reference section? '39' on line 1752 looks like a reference -- Missing reference section? '7' on line 1642 looks like a reference -- Missing reference section? '64' on line 1838 looks like a reference -- Missing reference section? '40' on line 1756 looks like a reference -- Missing reference section? '59' on line 1821 looks like a reference Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 66 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force 3 Internet Draft D. Mitzel 4 draft-iab-wirelessws-01.txt Nokia 5 Expires: February 18, 2000 August 2000 7 Overview of 2000 IAB Wireless Internetworking Workshop 9 STATUS OF THIS MEMO 11 This document is an Internet-Draft and is in full conformance with all 12 provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering Task 15 Force (IETF), its areas, and its working groups. Note that other groups 16 may also distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference material 21 or to cite them other than as "work in progress". 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt. 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Abstract 31 This document provides an overview of a workshop held by the Internet 32 Architecture Board (IAB) on wireless internetworking. The workshop was 33 hosted by Nokia in Mountain View, CA, USA on February 29 thru March 2, 34 2000. The goal of the workshop was to assess current and future uses of 35 Internet technology in wireless environments, to make recommendations on 36 research and standardization tasks to improve acceptance of Internet 37 network and transport protocols in wireless environments, and to evalu- 38 ate methods to improve communication and collaboration among Internet 39 standards working groups and those of the telephony and wireless sec- 40 tors. This report summarizes the conclusions and recommendations of the 41 IAB on behalf of the IETF community. 43 Comments should be submitted to the IAB-Wireless-Workshop@ietf.org mail- 44 ing list. 46 Table of Contents 48 1 Introduction . . . . . . . . . . . . . . . . . . . . . . 4 49 2 Presentation Overview . . . . . . . . . . . . . . . . . . 5 50 3 Discussion and Observations . . . . . . . . . . . . . . . 10 51 3.1 Discussion on "Walled Garden" Service Model . . . . . . . 10 52 3.2 Discussion on Mobility and Roaming . . . . . . . . . . . 11 53 3.2.1 Discussion on Mobility and Roaming Model . . . . . . . . 11 54 3.2.2 Discussion on Mobility and Roaming Protocols . . . . . . 12 55 3.2.3 Discussion on Mobility and Roaming Services . . . . . . . 12 56 3.3 Discussion on Security Model . . . . . . . . . . . . . . 13 57 3.3.1 Discussion on User Identity . . . . . . . . . . . . . . . 13 58 3.3.2 Discussion on WAP Security . . . . . . . . . . . . . . . 14 59 3.3.3 Discussion on 3G Network Security . . . . . . . . . . . . 14 60 3.4 Discussion on Transports . . . . . . . . . . . . . . . . 15 61 3.4.1 Discussion on Link Characteristics and Mobility 62 Effect on Transport . . . . . . . . . . . . . . . . . . . . . . . . 15 63 3.4.2 Discussion on WAP Transport . . . . . . . . . . . . . . . 16 64 3.4.3 Discussion on IETF Transport Activities . . . . . . . . . 17 65 3.5 Discussion on Aeronautical Telecommunication Network 66 (ATN) Routing Policy . . . . . . . . . . . . . . . . . . . . . . . . 18 67 3.6 Discussion on QoS Services . . . . . . . . . . . . . . . 19 68 3.6.1 Discussion on "Last Leg" QoS . . . . . . . . . . . . . . 19 69 3.6.2 Discussion on Path QoS Discovery . . . . . . . . . . . . 19 70 3.7 Discussion on Header Compression . . . . . . . . . . . . 20 71 3.8 Discussion on Applications Protocols . . . . . . . . . . 21 72 3.9 Discussion on Proxy Agents . . . . . . . . . . . . . . . 22 73 3.10 Discussion on Adoption of IPv6 . . . . . . . . . . . . . 22 74 3.11 Discussion on Signaling . . . . . . . . . . . . . . . . . 23 75 3.12 Discussion on Interactions Between IETF and Other 76 Standards Organizations . . . . . . . . . . . . . . . . . . . . . . 24 77 4 Recommendations . . . . . . . . . . . . . . . . . . . . . 25 78 4.1 Recommendations on Fostering Interaction with Non- 79 Internet Standards Organizations . . . . . . . . . . . . . . . . . . 25 80 4.1.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 81 4.1.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 82 4.1.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 83 4.2 Recommendations for Dealing with "Walled Garden" 84 Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 85 4.2.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 86 4.2.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 87 4.3 Recommendations on IPv4 and IPv6 Scaling . . . . . . . . 27 88 4.3.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 89 4.3.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 90 4.3.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 91 4.3.4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 92 4.4 Recommendations on IPv4 and IPv6 Mobility . . . . . . . . 28 93 4.4.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 94 4.4.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 95 4.4.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 96 4.5 Recommendations on TCP and Transport Protocols . . . . . 29 97 4.5.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 98 4.5.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 99 4.5.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 100 4.5.4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 101 4.5.5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 102 4.5.6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 103 4.6 Recommendations on Routing . . . . . . . . . . . . . . . 31 104 4.6.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 105 4.6.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 106 4.7 Recommendations on Mobile Host QoS Support . . . . . . . 32 107 4.7.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 108 4.7.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 109 4.8 Recommendations on Application Mobility . . . . . . . . . 32 110 4.9 Recommendations on TCP/IP Performance Characteriza- 111 tion in WAP-like Environment . . . . . . . . . . . . . . . . . . . . 32 112 4.10 Recommendations on Protocol Encoding . . . . . . . . . . 33 113 4.11 Recommendations on Inter-Domain AAA Services . . . . . . 33 114 4.12 Recommendations on Bluetooth . . . . . . . . . . . . . . 33 115 4.13 Recommendations on Proxy Architecture . . . . . . . . . . 34 116 4.14 Recommendations on Justifying IPv6-based Solutions 117 for Mobile / Wireless Internet . . . . . . . . . . . . . . . . . . . 34 118 5 Security Considerations . . . . . . . . . . . . . . . . . 34 119 6 Acknowledgments . . . . . . . . . . . . . . . . . . . . . 35 120 7 Bibliography . . . . . . . . . . . . . . . . . . . . . . 35 121 A Participants . . . . . . . . . . . . . . . . . . . . . . 39 122 B Author's Address . . . . . . . . . . . . . . . . . . . . 40 123 C Changes from draft-iab-wirelessws-00.txt . . . . . . . . 40 124 1 Introduction 126 Wireless technology, including wireless LANs, data transfer over cellu- 127 lar radio (GSM, 3GPP, etc), and mobile operations from aircraft and near 128 earth spacecraft are becoming increasingly important. Some market pro- 129 jections suggest that a mobile Internet in parallel with or augmenting 130 the wired Internet may be comparable in size to the wired Internet as 131 early as 2003. 133 The wireless operators have not, however, chosen to use IPv4, TCP, full 134 HTTP/HTML, and other applications for a variety of reasons. These relate 135 to edge device cost, bandwidth limitations, perceived protocol imperfec- 136 tions, unnecessary complexities, the chattiness of the application pro- 137 tocols, and network layer addressing issues. Unfortunately, this creates 138 some serious issues at the wired/wireless demarcation: end to end opera- 139 tion is sacrificed, security is compromised, and automated content modi- 140 fication in some form becomes necessary. The IAB considers these to be 141 serious fundamental issues, which will in time be a serious impediment 142 to the usability of the combined Internet if not addressed. 144 The Internet Architecture Board (IAB), on February 29 thru March 2, 145 2000, held an invitational workshop on wireless internetworking. The 146 goal of the workshop was to assess current and future uses of Internet 147 technology in wireless environments, to make recommendations on research 148 and standardization tasks to improve acceptance of Internet network and 149 transport protocols in wireless environments, and to evaluate methods to 150 improve communication and collaboration among Internet standards working 151 groups and those of the telephony and wireless sectors. 153 The following topics were defined for discussion: 155 + Local area wireless technologies 157 + Cellular wireless technologies 159 + Wireless Application Protocol (WAP) 161 + Near-space and aviation wireless applications 163 + Voice over IP (VoIP) over wireless networks 165 + Security over wireless networks 167 + Transport and QoS over wireless networks 169 + Use of WWW protocols over wireless and small screen devices 170 + Addressing requirements for wireless devices 172 + Compression and bit error requirements for wireless networks 174 The fundamental question addressed in these discussion is "what are the 175 issues, and what really needs to be done to unify the Internet below the 176 application layer." Applications will also need to be addressed, but 177 were perceived to be more than could be usefully discussed in a three- 178 day workshop, and probably require different expertise. 180 Section 2 presents a concise overview of the individual presentations 181 made during the workshop. References to more extensive materials are 182 provided. Details on major discussion topics are provided in section 3. 183 Section 4 presents the recommendations made to wireless operators, IRTF, 184 and IETF on the architectural roadmap for the next few years. It should 185 be noted that not all participants agreed with all of the statements, 186 and it was not clear whether anyone agreed with all of them. However, 187 the recommendations made are based on strong consensus among the partic- 188 ipants. Finally, section 5 highlights references to security considera- 189 tions discussed, appendix A lists contact information of workshop par- 190 ticipants, and appendix B lists the author contact information. 192 2 Presentation Overview 194 Title: Overview of Wireless IP Devices (Network Implications...) 196 Presenter: Heikki Hammainen 198 Reference: 199 http://www.iab.org/IAB-wireless-workshop/talks/hh-IABpub.PDF, 200 http://www.iab.org/IAB-wireless-workshop/talks/hh-IABpub.ppt 202 Overview: 204 Title: Overview of IEEE 802.11 Wireless LAN's & Issues Running IP 205 over IEEE 802.11? 207 Presenter: Juha Ala-Laurila 209 Reference: 210 http://www.iab.org/IAB-wireless-work- 211 shop/talks/IEEE80211_IP.ppt 213 Overview: 215 Title: Overview of Bluetooth Wireless & Issues Running IP over 216 Bluetooth? 218 Presenter: Pravin Bhagwat 220 Reference: 221 http://www.iab.org/IAB-wireless-workshop/talks/BT- 222 overview.PDF, 223 http://www.iab.org/IAB-wireless-workshop/talks/BT-overview.ppt 225 Overview: 227 Title: Overview of Cellular Data Systems & Approaches to more IP 228 centric Cellular Data System 230 Presenter: Jonne Soinien 232 Reference: 233 http://www.iab.org/IAB-wireless-workshop/talks/Cellu- 234 lar_JSo.PDF, 235 http://www.iab.org/IAB-wireless-workshop/talks/Cellu- 236 lar_JSo.ppt 238 Overview: 240 Title: IP Packet Data Service over IS-95 CDMA 242 Presenter: Phil Karn 244 Reference: 245 http://www.iab.org/IAB-wireless-workshop/talks/karn/index.htm 247 Overview: 249 Title: Wireless Internet Networking 251 Presenter: Chih-Lin I 253 Reference: 254 http://www.iab.org/IAB-wireless-workshop/talks/IAB000229.PDF, 255 http://www.iab.org/IAB-wireless-workshop/talks/IAB000229.ppt 257 Overview: 259 Title: Mobile IP in Cellular Data Systems 261 Presenter: Charlie Perkins 263 Reference: 264 http://www.iab.org/IAB-wireless-workshop/talks/WLIP99.PDF, 265 http://www.iab.org/IAB-wireless-workshop/talks/WLIP99.ppt 267 Overview: 269 Title: Overview of WAP 271 Presenter: Alastair Angwin 273 Reference: 274 http://www.iab.org/IAB-wireless-workshop/talks/iab-wap-1.pdf 276 Overview: 278 Title: Mobile Wireless Internet Forum (MWIF) 280 Presenter: Alastair Angwin 282 Reference: 283 http://www.iab.org/IAB-wireless-workshop/talks/MWIF_TC_Presen- 284 tation.PDF, 285 http://www.iab.org/IAB-wireless-workshop/talks/MWIF_TC_Presen- 286 tation.ppt 288 Overview: 290 Title: Some WAP History 292 Presenter: Jerry Lahti 294 Reference: 295 http://www.iab.org/IAB-wireless-workshop/talks/waphist.PDF, 296 http://www.iab.org/IAB-wireless-workshop/talks/waphist.ppt 298 Overview: 300 Title: Near-space Wireless Applications 302 Presenter: Mark Allman 304 Reference: 305 http://www.iab.org/IAB-wireless-workshop/talks/allman-iab- 306 wireless.pdf, 307 http://www.iab.org/IAB-wireless-workshop/talks/allman-iab- 308 wireless.ps 310 Overview: 312 Title: Air Traffic / Aviation Wireless 313 Presenter: Chris Wargo 315 Reference: 316 http://www.iab.org/IAB-wireless-workshop/talks/wargo-talk.PDF, 317 http://www.iab.org/IAB-wireless-workshop/talks/wargo-talk.ppt 319 Overview: 321 Title: VoIP over Wireless 323 Presenter: Christian Huitema 325 Reference: 326 http://www.iab.org/IAB-wireless-workshop/talks/iab-wless- 327 voip.PDF, 328 http://www.iab.org/IAB-wireless-workshop/talks/iab-wless- 329 voip.ppt 331 Overview: 333 Title: Security Issues in Wireless Networks and Mobile Computing 335 Presenter: N. Asokan 337 Reference: 338 http://www.iab.org/IAB-wireless-workshop/talks/mobile-secu- 339 rity.PDF, 340 http://www.iab.org/IAB-wireless-workshop/talks/mobile-secu- 341 rity.ppt 343 Overview: 345 Title: Security for Mobile IP in 3G Networks 347 Presenter: Pat Calhoun 349 Reference: 350 http://www.iab.org/IAB-wireless-workshop/talks/mip-sec-3g.PDF, 351 http://www.iab.org/IAB-wireless-workshop/talks/mip-sec-3g.ppt 353 Overview: 355 Title: On Inter-layer Assumptions (A View from the Transport Area) 357 Presenter: Mark Handley 359 Reference: 360 http://www.iab.org/IAB-wireless-workshop/talks/handley- 361 wireless.pdf, 362 http://www.iab.org/IAB-wireless-workshop/talks/handley-wire- 363 less.ps 365 Overview: 367 Title: Does current Internet Transport work over Wireless? 369 Presenter: Sally Floyd 371 Reference: 372 http://www.iab.org/IAB-wireless-workshop/talks/IAB-wireless- 373 Mar00.pdf, 374 http://www.iab.org/IAB-wireless-workshop/talks/IAB-wireless- 375 Mar00.ps 377 Overview: 379 Title: QOS for Wireless (DiffServ, IntServ, other?) 381 Presenter: Lixia Zhang 383 Reference: 384 http://www.iab.org/IAB-wireless-workshop/talks/zhang-feb- 385 IAB.PDF, 386 http://www.iab.org/IAB-wireless-workshop/talks/zhang-feb- 387 IAB.ppt 389 Overview: 391 Title: Do current WWW Protocols work over Wireless and Small Screen 392 Devices? 394 Presenter: Gabriel Montenegro 396 Reference: 397 http://www.iab.org/IAB-wireless-workshop/talks/wireless- 398 www.PDF, 399 http://www.iab.org/IAB-wireless-workshop/talks/wireless- 400 www.ppt 402 Overview: 404 Title: Compression & Bit Error Requirements for Wireless 406 Presenter: Mikael Degermark 407 Reference: 408 http://www.iab.org/IAB-wireless-workshop/talks/iab-hc.PDF, 409 http://www.iab.org/IAB-wireless-workshop/talks/iab-hc.ppt 411 Overview: 413 Title: Addressing Requirements for Wireless Devices & IPv6 415 Presenter: Bob Hinden 417 Reference: 418 http://www.iab.org/IAB-wireless-workshop/talks/Addressing- 419 IPv6.PDF, 420 http://www.iab.org/IAB-wireless-workshop/talks/Addressing- 421 IPv6.ppt 423 Overview: 425 3 Discussion and Observations 427 During the workshop presentations a number of issues were discussed and 428 observations made. The following sections 3.1 -- 3.12 summarize these 429 discussion and observations. Rather than organizing the material lin- 430 early by presentation, it is grouped according to common "themes" and 431 issues. 433 3.1 Discussion on "Walled Garden" Service Model 435 Presentations from members involved in the cellular wireless (3GPP, 436 3G.IP, MWIF) and WAP environments quickly illustrated a significant dif- 437 ference in protocol specification and service models from that typically 438 assumed by the Internet community. These communities focus on defining a 439 profile (set of protocols and operational parameters) that combine to 440 provide a well defined user service. In addition, the carriers typically 441 prefer to have complete (or as much as possible) control over the entire 442 service, including user access device, transmission facilities, and ser- 443 vice "content". This style of service model appears to have been inher- 444 ited from the classic telephony provider model. The term "walled garden" 445 was coined to describe the resulting captive customer economic and ser- 446 vice model. That is, the user is constrained within the limits of the 447 service provided by the carrier with limited ability to extend features 448 or access services outside the provider. 450 The "walled garden" service model is in stark contrast to the "open" 451 service assumed in the Internet. The application, access device, and 452 service content may each be controlled by a different entity, and the 453 service provider is typically viewed as little more than a "bit pipe". 454 Additionally, specification typically define a standalone protocol or 455 application rather than the set of features and interoperation with 456 other components required to deploy a commercial service. 458 Some discussion focused on whether cellular carriers could be persuaded 459 to transition toward the Internet "open" service model. Responses indi- 460 cated that there was little hope of this as carriers will always fight 461 being reduced to a "bit pipe", fearing they cannot sustain sufficient 462 revenues without the value added services. An additional point raised 463 was that the closed model of the "walled garden" simplifies a number of 464 issues, such as security, authorization, and billing when the entire 465 network is considered secured and controlled under a single administra- 466 tion. These simplification can eliminate roadblocks to service deploy- 467 ment before scalable, interdomain solutions are available. 469 Even though there seems little hope of evolving carriers away from the 470 "walled garden" service in the short term, there was significant value 471 in recognizing its presence. This led to observations that "walled gar- 472 den" Internet-based services will operate somewhat like current intranet 473 services. Also, mechanisms should be investigated to simplify interoper- 474 ation and controlled access to the Internet. Finally, the difference 475 between Internet protocol specification contrasted to service profiles 476 highlights some of the confusion those in the telephony environment 477 encounter when attempting to incorporate Internet capabilities. 479 Much of the current work in extending Internet-based services to cellu- 480 lar customers has focused on data services such as email or web access. 481 One observation on the reluctance of carriers to release any control 482 over services was that this may be an impediment to adoption of Inter- 483 net-based voice services. Current work on voice over IP (VoIP) and call 484 signaling (SIP [30]) loosens control over these services, much of the 485 functionality is moved into the SIP agent with the carrier being reduced 486 to an access provider (i.e., "bit pipe"). 488 3.2 Discussion on Mobility and Roaming 490 An inherent characteristic of wireless systems is their potential for 491 accommodating device roaming and mobility. Some discussion focused on 492 the model of mobility presented to the user. There was also considerable 493 interest and discussion on protocols employed, using cellular telephony 494 and/or IP-based solutions. Finally, there was some interest in exploring 495 new services enabled by mobility. 497 3.2.1 Discussion on Mobility and Roaming Model 499 There was considerable discussion and concern over what style of mobil- 500 ity and roaming needs to be supported. Current usage in the Internet is 501 dominated by the mode where a user performs some actions at one loca- 502 tion, then shuts down and moves, followed by restart at a new location. 504 3G.IP uses the term "macro mobility" to describe this mode. 506 The discussion attempted to discern whether the current mode of usage is 507 a perceived limitation introduced by current protocols. A clear consen- 508 sus could not be achieved. There was agreement that introduction of this 509 "macro mobility" roaming is a worthwhile first step. However, that was 510 immediately followed by questions on whether it is a sufficient first 511 step, and warning not to stop at this level. There seems significant 512 issues for continued investigation related to enabling continual usage 513 of a device during roaming ("micro mobility") and the ability to 514 retrieve previous connections after a roaming event. 516 3.2.2 Discussion on Mobility and Roaming Protocols 518 Selection between cellular and IP protocols in support of roaming pro- 519 vided another topic for significant discussion. Cellular operators have 520 already deployed protocols providing significant support for roaming. 521 This has led several efforts, such as 3GPP and 3G.IP, toward architec- 522 ture relying on telephone system for all mobility support, hiding roam- 523 ing from the IP layer. 525 Arguments for cellular-based roaming centered on concerns about the 526 mobile IP model. There was concern that home agent and foreign agent 527 involvement in delivery might introduce bottleneck, and the perception 528 that mobile IP handoff is too slow. A rebuttal offered was that IETF 529 mobileip working group is introducing hierarchy and route optimization 530 to improve performance and robustness [50], and there was disagreement 531 on the point regarding slow handoff under mobile IP. 533 Detriments to the cellular-based roaming include the lack of IP support 534 out to the mobile device and the added tunneling protocols and overhead 535 required. Additionally, roaming is less well defined when traversing 536 service provider boundaries and may involve highly non-optimal forward- 537 ing path. There appears significant work remaining to reach convergence 538 on opinions, and additional investigation to support roaming across cel- 539 lular, WLAN, and IP boundaries. 541 3.2.3 Discussion on Mobility and Roaming Services 543 3G.IP mobility model is primarily focused on providing ubiquitous ser- 544 vice across a range of access media. However, the presentation also 545 highlighted a desire to develop new "location based" services. Examples 546 presented include locating nearby services or receiving advertisement 547 and solicitations from nearby business. 549 There are several Internet protocols defined, such as anycast service 550 [47] and SLP [28], that may aid in developing location based services. 551 However, there was considerable frustration on the part of 3G.IP in that 552 there appears little commercial support of these protocols, and even 553 less direction on how to assemble and coordinate the required protocols 554 to deploy the desired services. 556 This exchange illustrated the disconnect between interpreting Internet 557 standards and telephony service profiles. First, in the Internet many 558 protocols are defined but many are optional. Protocol support is typi- 559 cally driven by market demand, which can lead to "chicken and egg" prob- 560 lem. Secondly, individual protocols and applications are developed 561 rather than complete profile to compose a commercial service. For this 562 service, evaluating the usage and scalability of service discovery pro- 563 tocols appears to be an area open for further investigation. 565 3.3 Discussion on Security Model 567 Mobility and wireless environments introduce many complexities and 568 potential attacks to user authentication and privacy. In addition to the 569 discussion presented below, there was an overriding statement made 570 regarding the methodology that must be followed for all security proto- 571 col development. It was felt quite strongly that the only chance for 572 success is that the definition be done in a public forum, allowing full 573 disclosure of all algorithms and thorough review by security experts. 574 Stated an alternate way, defining protocols in a closed forum relying on 575 cellphone manufacturers, or other non-experts on IP security, is very 576 likely to create security exposures. 578 3.3.1 Discussion on User Identity 580 Storage of user identity can have significant effect on device usage and 581 device portability. Discussion focused on whether identity should be 582 tied to the mobile device or a transferable SIM card. Fixing identifica- 583 tion with the device may simplify manufacture and provide some tamper 584 resistance, however it makes it very difficult to deploy a public device 585 taking on the identity of the user. These alternative also affect trans- 586 fer of identity and configuration state on device replacement or 587 upgrade. 589 A related topic revolves around the user desire to employ a single 590 device but to take on a different identity and privilege based on the 591 usage at hand (e.g., to gain corporate access, home access, or Internet 592 access). The ability and ease of assuming these multiple identities may 593 be highly dependent on the model of identity integration, as discussed 594 above. Discussion highlighted potential pitfalls based on tieing of 595 device and user identities. IPsec use of device IP address inhibits 596 roaming capabilities as the address may change based on location, and 597 precludes distinguishing identity and capabilities for current usage. 598 IPsec requires additional work to accommodate this added flexibility. 600 A final topic of discussion on user identity establishment was whether 601 possession of the device is sufficient, or whether the user should be 602 required to authenticate to the device. In the real world the first 603 alternative is exemplified by the credit card model, while the second is 604 more analogous to the ATM card where the user must also provide a PIN 605 code. Both models seem useful in the real world, and it's likely both 606 will have uses in wireless networking. 608 3.3.2 Discussion on WAP Security 610 WAP wireless transport security (WTLS) is based on TLS [20], with opti- 611 mized handshake to allow frequent key exchange. The security service 612 employs a "vertical" integration model, with protocol components 613 throughout the network stack. Some argued that this is the wrong model. 614 A better approach may have been a security layer with well defined 615 interfaces. This could allow for later tradeoffs among different proto- 616 cols, driven by market, applications, and device capabilities. 618 Additional statements argued that the WAP security model illustrates 619 dangers from optimizing for a limited usage domain ("walled garden"). 620 Content provider systems requiring security (e.g., banks) must deploy a 621 special WAP proxy, which breaks the model of a single WAP "domain". Sim- 622 ilar issues are inherent in gatewaying to the Internet. 624 3.3.3 Discussion on 3G Network Security 626 The existing GSM/GPRS model uses long term shared secrets (embedded in 627 SIM card) with one-way authentication to the network, and with privacy 628 only provided on the access link. This is an example where the "walled 629 garden" service model has an advantage. Complete control over the ser- 630 vice access devices and network greatly reduces the range of security 631 concerns and potential attacks. 633 Future 3GPP and 3GPP2 plan to push IP all the way out to the wireless 634 device. An observation is that this results in more potential for expo- 635 sure of signaling and control plane to attacks. Desire is to perform 636 mutual authentication and securing of the network. This is a difficult 637 problem with additional issues remaining to be solved; however the 638 statement was made that relying on IP and open standards is more likely 639 to produce a provably secure network than former reliance on SS7 proto- 640 cols and obscurity. 642 Completing support for the security requirements of the 3GPP/3GPP2 net- 643 work seems to require resolving issues in two primary areas, AAA ser- 644 vices and mobile IP. AAA is required for authentication, authorization, 645 and billing. Remaining issues center around cross domain AAA, authenti- 646 cation using PKI, and there was considerable aversion to use of IPsec 647 and IKE protocols due to perceived overhead and delay. Mobile IP issues 648 revolve around solutions to reduce the security associations required 649 between mobile node and home agent, mobile node and foreign agent, and 650 the home and foreign agent. An interim solution being investigated 651 involves use of a RADIUS server [56]; however, there are concerns with 652 repeated dynamic key generation on each handoff or hiding some details 653 of handoffs, which may violate assumptions in mobile IP protocol [48]. 654 Evaluating requirements and addressing all of these open issues appears 655 to be an excellent opportunity for mutual cooperation on open standard- 656 ization and review. 658 3.4 Discussion on Transports 660 Discussion on transport protocols touched on a broad range of issues. 661 Concerns ranged from the effects of wireless link characteristics and 662 mobility effect on TCP, to development of new transport protocols such 663 as WAP Wireless Transaction Protocol (WTP). In addition, a significant 664 amount of time was spent reviewing ongoing efforts within the IETF on 665 TCP transport enhancements and investigation of new transports. 667 3.4.1 Discussion on Link Characteristics and Mobility Effect on Trans- 668 port 670 TCP makes assumptions on loss as congestion indication. The statement 671 was made that TCP was designed for links with about 1% corruption loss, 672 and provided that constraint is met then TCP should function properly. 673 Presentation on IS-95 CDMA-based data service showed that it conditions 674 line to provide 1--2% error rate with little correlation between loss. 675 Similar conditioning and Forward Error Correction (FEC) mechanisms may 676 be appropriate for other wireless and satellite systems [4]. This may 677 not be true for all wireless media, but it was interesting in the fact 678 that it indicates TCP should work properly on many wireless media. How- 679 ever, the amount of discussion and suggestions on TCP performance opti- 680 mizations showed that there can be a considerable gap between merely 681 working and working well. 683 One issue raised several times was related to the effects of non-conges- 684 tive loss on TCP performance. In the wireless environment non-congestive 685 loss may be more prevalent due to corruption loss (especially if the 686 wireless link cannot be conditioned to properly control error rate) or 687 an effect of mobility (e.g., temporary outage while roaming through an 688 area of poor coverage). These losses can have great detrimental effect 689 on TCP performance, reducing the transmission window and halving the 690 congestion window size. Much of the discussion focused on proposing 691 mechanisms to explicitly indicate a non-congestive loss to the TCP 692 source. Suggestions included a Non-Congestive Loss Indication (NCLI) 693 sent for instance when packet corruption loss is detected, or sending a 694 Source Encourage (SE) to stimulate source transmission at the end of an 695 outage. In addition to data corruption, wireless links can also 696 experience dropouts. In this situation any active TCP sessions will com- 697 mence periodic retransmissions, using an exponentially increasing back- 698 off timer between each attempt. When the link becomes available it may 699 be many seconds before the TCP sessions resume transmission. Mechanisms 700 to alleviate this problem, including packet caching and triggered 701 retransmission were discussed. The more generic form of all of these 702 mechanisms is one that allows the state of the layer two (datalink) sys- 703 tem to signal to the TCP session its current operating mode. Developing 704 a robust form of such a signaling mechanism, and integrating these sig- 705 nals into the end-to-end TCP control loop may present opportunities to 706 improve TCP transport efficiency for wireless environments. 708 TCP improvements have been incorporated to support "long" links (i.e., 709 those with large delay and bandwidth characteristics) [36], however con- 710 siderable expertise may still be required to tune socket buffers for 711 maximum performance. Some work has been done on auto-tuning buffers, 712 which shows promise [58]. An additional problem with large windows and 713 auto-tuning is the added header overheads. This may exasperate the prob- 714 lems of running TCP over low bandwidth links. Suggestions included to 715 explore dynamic negotiation of large window extensions in the middle of 716 a connection to alleviate these issues. A final issue raised with regard 717 to large window extensions is the corresponding large bursts and their 718 effect on congestion. There has been some investigation into pacing TCP 719 segment transmissions [41], however there is disagreement on the effec- 720 tiveness of this proposal [2]. 722 There was also concern regarding mobility effects on TCP performance. 723 TCP has implicit assumptions on bounding propagation delay. If delay 724 exceeds the smoothed round trip time plus four times the round trip 725 variance then the segment is considered lost, triggering the normal 726 backoff procedures. Could these assumptions be violated by variable 727 delays in a mobile environment? TCP also has arbitrary assumption that 728 three duplicate ACKs signal loss. Could this be violated by segment loss 729 or duplication during handoff? Work on D-SACK [25] may alleviate these 730 worries, detecting reordering and allowing for adaptive DUP-ACK thresh- 731 old. Finally, there was suggestion it might be appropriate to adapt 732 (e.g., trigger slow start) immediately after mobile handoff on the 733 assumption that path characteristics may differ. 735 3.4.2 Discussion on WAP Transport 737 WAPF considered TCP connection setup and teardown too expensive in terms 738 of bit overhead and latency when required for every transaction. WAPF 739 developed the Wireless Transaction Protocol (WTP), with some inspiration 740 from T/TCP [12]. WTP offers several classes of service ranging from 741 unconfirmed request to single request with single reply transaction. 742 Data is carried in the first packet and 3-way handshake eliminated to 743 reduce latencies. In addition acknowledgments, retransmission, and flow 744 control are provided. 746 Discussion on WTP centered on assessing details on its operation. 747 Although it incorporates mechanisms for reliability and flow control 748 there was concern that it may miss critical or subtle transport issues 749 learned through years of Internet research and deployment experience. 750 One potential area for disaster appeared to be the use of fixed retrans- 751 mission timers and lack of congestion control. This gave rise to sugges- 752 tions that the IETF write up more details on the history and tradeoffs 753 in transport design to aid others doing transport design work, and sec- 754 ondly that the IETF advocate that congestion control is not optional 755 when using rate adaptive transport protocols. 757 The remaining discussion on WAP transport primarily focused on ways to 758 share information. It was suggested that any results from WAPF study of 759 TCP shortcomings that led to its rejection might be useful for IETF 760 review as inputs for TCP modifications. Similar comments were raised on 761 study of T/TCP shortcomings and its potential exposure to Denial of Ser- 762 vice (DoS) attacks. It was also encouraged that WAPF members participate 763 in the IETF to directly contribute requirements and remain abreast of 764 current efforts on evolving TCP operation and introduction of new trans- 765 port (see discussion below in section 3.4.3). 767 3.4.3 Discussion on IETF Transport Activities 769 Discussion on transport work in the IETF presented a large array of 770 activities. Recent work on transport improvement includes path MTU, For- 771 ward Error Correction (FEC), large windows, SACK, NewReno Fast Recovery, 772 ACK congestion control, segment byte counting, Explicit Congestion Noti- 773 fication (ECN), larger initial transmit windows, and sharing of related 774 TCP connection state [3,4,5,6,24,25,43,53,63]. Work on new transports 775 includes SCTP [61] in the IETF Signaling Transport (sigtran) working 776 group and TCP-Friendly Rate Control (TFRC) [1] by researchers at ACIRI. 777 SCTP provides a reliable UDP-like protocol supporting persistent associ- 778 ations and in-order delivery with congestion control. TFRC is targeted 779 at unreliable, unicast streaming media. Finally, work in the IETF End- 780 point Congestion Management (ecm) working group is looking at standard- 781 izing congestion control algorithms, and work in the Performance Impli- 782 cations of Link Characteristics (pilc) working group is characterizing 783 performance impacts of various link technologies and investigating per- 784 formance improvements. 786 This vast array of ongoing research and standards development seemed a 787 bit overwhelming, and there was considerable disagreement on the perfor- 788 mance and applicability of several TCP extensions. However, this discus- 789 sion did raise a couple of key points. First, transport work within the 790 Internet community is not stagnant, there is a significant amount of 791 interest and activity in improvement to existing protocols and 792 exploration of new protocols. Secondly, the work with researchers in 793 satellite networking has demonstrated the tremendous success possible in 794 close collaboration. The satellite networking community was dissatisfied 795 with initial TCP performance on long delay links. Through submission of 796 requirements and collaborative investigation a broad range of improve- 797 ments have been proposed and standardized to address unique characteris- 798 tics of this environment. This should hopefully set a very positive 799 precedent to encourage those in the wireless sector to pursue similar 800 collaboration in adoption of Internet protocols to their environment. 802 3.5 Discussion on Aeronautical Telecommunication Network (ATN) Routing 803 Policy 805 The Aeronautical Telecommunication Network (ATN) has goals to improve 806 and standardize communications in the aviation industry. This ranges 807 across air traffic management and control, navigation and surveillance, 808 all the way up to passenger telephone service and entertainment. This 809 also involves integration of both fixed ground segments and mobile air- 810 craft. Supporting the ATN architecture using Internet protocols may 811 introduce additional requirements on the routing infrastructure. 813 Current ATN views each aircraft as an autonomous network (AS) with 814 changing point of attachment as it "roams" through different airspace. 815 Addressing information associated with the aircraft is fixed, which 816 makes route aggregation difficult since they're not related to topology, 817 and also increases the frequency of updates. Additionally, the aircraft 818 may be multiply attached (within coverage of multiple ground and space- 819 based access networks), requiring routing policy support for path selec- 820 tion. Finally, QoS path selection capabilities may be beneficial to 821 arbitrate shared access or partition real-time control traffic from 822 other data traffic. 824 Initial prototype of ATN capabilities have been based on ISO IDRP [33] 825 path selection and QoS routing policy. There was some discussion whether 826 IDRP could be adopted for use in an IP environment. There was quick 827 agreement that the preferred solution within the IETF would be to 828 advance BGP4++ [8,54] as an IDRP-like replacement. This transitioned 829 discussion to evaluation of ATN use of IDRP features and their equiva- 830 lent to support in BGP. Several issues with BGP were raised for further 831 investigation. For example, whether BGP AS space is sufficient to accom- 832 modate each aircraft as an AS? Also issues with mobility support; can 833 BGP provide for dynamically changing peering as point of attachment 834 changes, and alternative path selection policies based on current peer- 835 ings? A significant amount of additional investigation is required to 836 fully assess ATN usage of IDRP features, especially in the QoS area. 837 These could lead to additional BGP requirements, for instance to effect 838 different prioritization or path selection for aircraft control vs. pas- 839 senger entertainment traffic. 841 3.6 Discussion on QoS Services 843 Enabling support for voice and other realtime services along with data 844 capabilities requires Quality of Service (QoS) features to arbitrate 845 access to the limited transmission resources in wireless environment. 846 The wireless and mobile environment requires QoS support for the last 847 leg between the mobile device and network access point, accommodating 848 roaming and unique characteristics of the wireless link. 850 In addition to the discussion presented below, it was felt quite 851 strongly that it is critical any QoS facility be provided as an underly- 852 ing service independent of payload type. That is, there should be no 853 built in knowledge of voice or other application semantics. This 854 results in a feature that can be leveraged and easily extended to sup- 855 port new applications. 857 3.6.1 Discussion on "Last Leg" QoS 859 Discussion on voice over IP (VoIP) emphasized that (wireless) access 860 link is typically the most constrained resource, and while contention 861 access (CSMA) provides good utilization for data it is not ideal for 862 voice. Two models were identified as potential solution in VoIP archi- 863 tecture. The first is to have the wireless device directly signal the 864 local access router. A second alternative is to have the call control 865 element (SIP agent [30]) "program" the edge router. This tradeoff seemed 866 to be an area open for additional investigation, especially given the 867 complications that may be introduced in the face of mobility and roaming 868 handoffs. This appears a key component to solve for success in VoIP 869 adoption. 871 Work within the IEEE 802.11 WLAN group identified similar requirements 872 for QoS support. That group is investigating a model employing two 873 transmission queues, one for realtime and one for best-effort traffic. 874 Additional plans include mapping between IP DiffServ markings [14,46] 875 and IEEE 802 priorities. 877 The statement was also made that QoS over the wireless link is not the 878 fundamental problem, rather it is handling mobility aspects and seemless 879 adaptation across handoffs without service disruption. There were con- 880 cerns about mechanisms establishing per-flow state (RSVP [13]). Issues 881 include scaling of state, and signaling overhead and setup delays on 882 roaming events. DiffServ [9] approach allows allocating QoS for aggre- 883 gate traffic class, which simplifies roaming. However, DiffServ requires 884 measurement and allocation adjustment over time, and policing to limit 885 amount of QoS traffic injected. 887 3.6.2 Discussion on Path QoS Discovery 888 The HDR high speed wireless packet data system under development at 889 Qualcomm highlights unique characteristics of some wireless media. This 890 system provides users a channel rate between 38.4Kb/s and 2.4Mb/s, with 891 throughput dependent on channel loading and distance from network access 892 point. This gave rise to considerable discussion on whether it might be 893 possible to discover and provide feedback to the application regarding 894 current link or path QoS being received. This might enable some form of 895 application adaptation. 897 In the case of the HDR system it was indicated that no such feedback is 898 currently available. Additionally, it was argued that this is in accord 899 with the current Internet stack model, which does not provide any mecha- 900 nisms to expose this type of information. Counter arguments stated that 901 there are growing demands in Internet QoS working groups requesting 902 exposure of this type of information via standardized APIs. Members 903 working on GPRS protocols also indicated frustration in deploying QoS 904 capabilities without exposure of this information. This clearly seemed a 905 topic for further investigations. 907 A final area of discussion on QoS discovery focused on the question of 908 how a server application might find out the capabilities of a receiver. 909 This could allow for application adaptation to client device and path 910 characteristics. One suggestion proposed use of RSVP payload, which is 911 able to transport QoS information. A second alternative is to push capa- 912 bility exchange and negotiation to the application layer. Discussion on 913 this topic was brief, as application issues were deemed outside the 914 workshop charter, however this also seems an area open for future inves- 915 tigation. 917 3.7 Discussion on Header Compression 919 A critical deterrent to Internet protocol adoption in the highly band- 920 width constrained wireless cellular environment is the bit overhead of 921 the protocol encoding. Examples presented highlighted how a voice appli- 922 cation (layered over IP [52,19], UDP [51], and RTP [57]) requires a min- 923 imum of 40 bytes of headers for IPv4 or 60 bytes for IPv6 before any 924 application payload (e.g., 24 byte voice sample). This overhead was also 925 presented as a contributing factor for the creation of WAP Wireless 926 Datagram Protocol (WDP) rather than IP for very low datarate bearers. 928 Discussion on header compression techniques to alleviate these concerns 929 focused on work being performed within the IETF Robust Header Compres- 930 sion (rohc) working group. This working group has established goals for 931 wireless environment, to conserve radio spectrum, to accommodate mobil- 932 ity, and to be robust to packet loss both before the point where com- 933 pression is applied and between compressor and decompressor. Additional 934 requirements established were that the technique be transparent, does 935 not introduce additional errors, and that it is compatible with common 936 protocol layerings (e.g., IPv4, IPv6, RTP/UDP/IP, TCP/IP). 938 The primary observation was that this problem is now largely solved! 939 The working group is currently evaluating the ROCCO [38] and ACE [42] 940 protocols, and expects to finalize its recommendations in the near 941 future. It was reported that these encodings have a minimum header of 1 942 byte and result in average overhead of less than 2 bytes for an 943 RTP/UDP/IP packet. There is some extra overhead required if transport 944 checksum is required and some issues still to be analyzed related to 945 interoperation with encryption and tunneling. 947 A detriment to IPv6 adoption often cited is its additional header over- 948 head, primarily attributed to its larger address size. A secondary 949 observation made was that it's believed that IPv6 accommodates greater 950 header compression than IPv4. This was attributed to the elimination of 951 the checksum and identification fields from the header. 953 Discussion on use of WWW protocols over wireless highlighted protocol 954 encodings as another potential detriment to their adoption. A number of 955 alternatives were mentioned for investigation, including use of a 956 "deflate" Content-Encoding, using compression with TLS [20], or 957 Bellovin's TCP filters. Observation was made that it could be beneficial 958 to investigate more compact alternative encoding of the WWW protocols. 960 3.8 Discussion on Applications Protocols 962 IETF protocol developments have traditionally taken the approach of pre- 963 ferring simple encode/decode and word alignment at the cost of some 964 extra bit transmissions. It was stated that optimizing protocol encoding 965 for bit savings often leads to shortcomings or limitations on protocol 966 evolution. However, it was also argued that environments where physical 967 limitations have an effect on transmission capacity and system perfor- 968 mance may present exceptions where optimized encodings are beneficial. 969 Cellular wireless and near-space satellite may fall into this category. 971 The WAP protocols exhibit several examples where existing Internet pro- 972 tocols were felt to be too inefficient for adoption with very low 973 datarate bearer services and limited capability devices. The WAP Wire- 974 less Session Protocol (WSP) is based on HTTPv1.1 [23], however WSP 975 incorporates several changes to address perceived inefficiencies. WSP 976 uses a more compact binary header encoding and optimizations for effi- 977 cient connection and capability negotiation. Similarly, the WAP Wire- 978 less Application Environment (WAE) uses tokenized WML and a tag-based 979 browser environment for more efficient operation. 981 Additional requests for more efficient and compact protocol encodings, 982 and especially improved capability negotiation were raised during dis- 983 cussion on usage of WWW protocols with wireless handheld devices. 985 Finally, work within the near-space satellite environment has pointed 986 out other physical limitations that can affect performance. In this case 987 the long propagation delays can make "chatty" protocols highly ineffi- 988 cient and unbearable for interactive use. This environment could benefit 989 from protocols that support some form of "pipelining" operation. 991 There seemed broad agreement that many of these observations represent 992 valid reasons to pursue optimization of protocol operations. Investiga- 993 tion of compact protocol encoding, capability negotiation, and minimiz- 994 ing or overlapping round trips to complete a transaction could all lead 995 to improved application performance across a wide range of environments. 997 3.9 Discussion on Proxy Agents 999 Proxy agents are present in a number of the wireless and mobile archi- 1000 tectures. They're often required to gateway between communication 1001 domains; terminate tunnel and translate between telephony system and 1002 Internet protocols (GPRS), or to escape the "walled garden" (WAP). In 1003 conjunction with limited capability handheld devices a proxy might be 1004 deployed to offload expensive processing such as public key operations, 1005 perform content filtering, or provide access to "backend" applications 1006 (e.g., email, calendar, database). In other cases the proxy may be 1007 required to work around protocol deployment limitations (e.g., NAT with 1008 limited IPv4 addresses). 1010 The discussion on proxy agents primarily recognized that there are a 1011 range of proxy agent types. Proxies may operate by intercepting and 1012 interpreting protocol packets, or by hijacking or redirecting connec- 1013 tions. Some types of proxy break the Internet end-to-end communication 1014 and security models. Other proxy architectures may limit system scala- 1015 bility due to state or performance constraints. There was some desire 1016 to conduct further study of proxy agent models to evaluate their effect 1017 on system operation. 1019 3.10 Discussion on Adoption of IPv6 1021 Projections were presented claiming 1200 million cellular (voice) sub- 1022 scribers, 600 million wired stations on the Internet, and over 600 mil- 1023 lion wireless data ("web handset") users by the year 2004. Right up 1024 front there was caution about these projections, especially the wireless 1025 data since it is highly speculative with little history. Secondly, 1026 there was some doubt regarding potential for significant revenues from 1027 user base over 1 billion subscribers; this may be pushing the limits of 1028 world population with sufficient disposable income to afford these 1029 devices. However, there was broad consensus that cellular and Internet 1030 services are going to continue rapid growth and that wireless data ter- 1031 minals have potential to form a significant component of the total 1032 Internet. These conclusions seemed to form the basis for many additional 1033 recommendations to push for adoption of IPv6 protocols in emerging (3G) 1034 markets. 1036 In nearly all the presentations on 3G cellular network technologies dis- 1037 cussion on scaling to support the projected large number of wireless 1038 data users resulted in strong advocacy by the Internet representatives 1039 for adoption of IPv6 protocols. There were some positive signs that 1040 groups have begun investigation into IPv6. For example, 3GPP has already 1041 defined IPv6 as an option in their 1998 and 1999 specifications (release 1042 R98 and R99), and are considering specifying IPv6 as mandatory in the 1043 release 2000. The MWIF effort is also cognizant of IPv4 and IPv6 issues 1044 and is currently wrestling with their recommendations in this area. 1046 Although there was limited positive signs on IPv6 awareness, indication 1047 is that there are long fights ahead to gain consensus for IPv6 adoption 1048 in any of the 3G standards efforts. There was considerable feedback that 1049 the telephony carriers perceive IPv6 as more difficult to deploy, 1050 results in higher infrastructure equipment expenses, and adds difficulty 1051 in interoperation and gatewaying to the current (IPv4) Internet. Argu- 1052 ments for sticking with IPv4 primarily came down to the abundance and 1053 lower pricing of IPv4-based products, and secondary argument of risk 1054 aversion; there is currently minimal IPv6 deployment or operational 1055 experience and expertise, and the carriers do not want to drive develop- 1056 ment of this expertise. Finally, some groups argue IPv4 is sufficient 1057 for "walled garden" use, using IPv4 private address space (i.e., the 1058 "net 10" solution). 1060 One other area of concern regarding IPv6 usage is perceived memory and 1061 processing overhead and its effect on small, limited capability devices. 1062 This was primarily directed at IPv6 requirement for IPsec implementation 1063 to claim conformance. Arguments that continued increase in device capac- 1064 ity will obviate these concerns were rejected. It was stated that power 1065 constraints on these low-end devices will continue to force concerns on 1066 memory and processing overhead, and impact introduction of other fea- 1067 tures. There was no conclusion on whether IPsec could be made optional 1068 for these devices, or the effect if these devices were "non-compliant". 1070 Emerging 3G cellular networks appear ideal environment for IPv6 intro- 1071 duction. IPv6 addresses scaling requirements of wireless data user pro- 1072 jections and eliminates continued cobbling of systems employing (IPv4) 1073 private address space and NAT. This appears an area for IAB and Internet 1074 community to take a strong stance advocating adoption of IPv6 as the 1075 various 3G forums wrestle with their recommendations. 1077 3.11 Discussion on Signaling 1079 Discussion on signaling focused on call setup and control functions, and 1080 the effects of mobility. The 3G.IP group has investigated standardizing 1081 on either H.323 [32] or SIP [30]. Currently support seems to be split 1082 between the protocols, and neither seemed ideal without support for 1083 mobility. During discussion on VoIP it was presented that SIP does sup- 1084 port mobility, with graceful handling of mobile handoff, updating loca- 1085 tion information with remote peer, and even simultaneous handoff of both 1086 endpoints. The problem with SIP adoption seems to be its slow standard- 1087 ization brought about by focusing on the harder multicast model rather 1088 than expediting definition of a unicast "profile". There seems great 1089 need for IETF to expedite finalization of SIP, however some argued at 1090 this point it's likely many products will need to develop support for 1091 both SIP and H.323, and for their interoperation. 1093 A short discussion was also raised on whether it is the correct model to 1094 incorporate the additional protocol mechanisms to accommodate mobility 1095 into the SIP signaling. An alternative model might be to build on top of 1096 the existing mobile IP handoff facilities. There was no conclusion 1097 reached, however it seemed an area for further investigation. 1099 3.12 Discussion on Interactions Between IETF and Other Standards Organi- 1100 zations 1102 There were many examples where non-IETF standards organizations would 1103 like to directly adopt IETF standards to enable Internet (or similar) 1104 services. For example IEEE 802.11 WLAN relies on adoption of IETF stan- 1105 dards for mobile IP, end-to-end security, and AAA services. 3GPP is 1106 looking into the IETF work on header compression. WAPF derived its 1107 transport, security, and application environment from Internet proto- 1108 cols. At first glance these would seem successes for adoption of Inter- 1109 net technologies, however the decision to rely on IETF standards often 1110 introduced frustrations too. 1112 One common theme for frustration is differences in standardization pro- 1113 cedures. For instance, 3GPP follows a strict model of publishing recom- 1114 mendations yearly; any feature that cannot be finalized must be dropped. 1115 On the other hand the IETF working groups have much less formalized 1116 schedules, and in fact often seem to ignore published milestone dates. 1117 This has led to a common perception within other standards organizations 1118 that the IETF cannot deliver [on time]. 1120 A second area identified where IETF differs from other organizations is 1121 in publication of "system profile". For example defining interoperation 1122 of IPsec, QoS for VoIP and video conferencing, and billing as a "ser- 1123 vice". Wading through all the protocol specifications, deciding on 1124 optional features and piecing together the components to deliver a com- 1125 mercial quality service takes considerable expertise. 1127 Thirdly, there was often confusion about how to get involved in IETF 1128 standards effort, submit requirements, and get delivery commitments. 1130 Many people seem unaware and surprised at how open and simple it is to 1131 join in IETF standardization via working group meetings and mailing 1132 list. 1134 There wasn't really a large amount of discussions on ways to address 1135 these differences in standards practices. However, it did seem benefi- 1136 cial to understand these concerns and frustrations. It seemed clear 1137 there can be some benefits in improving communication with other stan- 1138 dards organizations and encouraging their participation in IETF activi- 1139 ties. 1141 4 Recommendations 1143 The IAB wireless workshop provided a forum for those in the Internet 1144 research community and in the wireless and telephony community to meet, 1145 exchange information, and discuss current activities on using Internet 1146 technology in wireless environments. However the primary goal from the 1147 perspective of the IAB was to reach some understanding on any problems, 1148 both technical or perceived deficiencies, deterring the adoption of 1149 Internet protocols in this arena. This section documents recommendations 1150 of the workshop on actions by the IAB and IESG, IRTF research efforts, 1151 and protocol development actions for the IETF to address these current 1152 deficiencies and foster wider acceptance of Internet technologies. 1154 4.1 Recommendations on Fostering Interaction with Non-Internet Standards 1155 Organizations 1157 A clear consensus of the workshop is that dialog needs to be improved. 1158 The Internet community should attempt to foster communication with other 1159 standards bodies, including WAPF, MWIF, 3GPP, 3G.IP, etc. The goal is 1160 to "understand each others problems", provide for requirements input, 1161 and greater visibility into the standardization process. 1163 4.1.1 1165 It was recommended to take a pragmatic approach rather than formalizing 1166 liaison agreements. The formalized liaison model is counter to the 1167 established Internet standards process, is difficult to manage, and has 1168 met with very limited success in previous trials. Instead, any relevant 1169 IETF working group should be strongly encouraged to consider and recom- 1170 mend potential liaison requirements within their charter. 1172 4.1.2 1174 It was recommended to avoid formation of jointly sponsored working 1175 groups and standards. Once again this has shown limited success in the 1176 past. The preferred mode of operation is to maintain separate standards 1177 organizations but to encourage attendance and participation of external 1178 experts within IETF proceedings and to avoid overlap. 1180 An exception to this style of partitioning meeting sponsorship is less 1181 formal activities, such as BOFs. It was recommended that sponsoring 1182 joint BOF could be beneficial. These could enable assembly of experts 1183 from multiple domains early in the process of exploring new topics for 1184 future standards activities. 1186 4.1.3 1188 A principle goal of fostering communication with other standards organi- 1189 zations is mutual education. To help in achieving this goal recommenda- 1190 tions were made related to documenting more of the history behind Inter- 1191 net standards and also in coordinating document reviews. 1193 It was recommended that IETF standards groups be encouraged to create or 1194 more formally document the reasons behind algorithm selection and design 1195 choices. Currently much of the protocol design history is difficult to 1196 extract, in the form of working group mail archives or presentations. 1197 Creation of these documents could form the basis to educate newcomers 1198 into the "history" and wisdom behind the protocols. 1200 It was recommended that mutual document reviews should be encouraged. 1201 This helps to disseminate information on current standards activities 1202 and provides an opportunity for external expert feedback. A critical 1203 hurdle that could severely limit the effectiveness of this type of 1204 activity is the intellectual property and distribution restrictions some 1205 groups place on their standards and working documents. 1207 4.2 Recommendations for Dealing with "Walled Garden" Model 1209 There are several perceived benefits to the "walled garden" (captive 1210 customer) model, similar to current deployment of "intranets". These 1211 range from simplified user security to "captive customer" economic mod- 1212 els. There was disagreement on the extent this deployment model might be 1213 perpetuated in the future. However it is important to recognize this 1214 model exists and to make a conscious decision on how to accommodate it 1215 and how it will affect protocol design. 1217 4.2.1 1219 It was strongly recommended that independent of the ubiquity of the 1220 "walled garden" deployment scenario that protocols and architectural 1221 decisions should not target this model. To continue the success of 1222 Internet protocols at operating across a highly diverse and heteroge- 1223 neous environment the IETF must continue to foster the adoption of an 1224 "open model". IETF protocol design must address seamless, secure, and 1225 scalable access. 1227 4.2.2 1229 Recognition that the "walled garden" model has some perceived benefits 1230 led to recommendations to better integrate it into the Internet archi- 1231 tecture. These focused on service location and escape from the "walled 1232 garden". 1234 It was recommended to investigate standard protocols for service and 1235 proxy discovery within the "walled garden" domain. There are already a 1236 number of candidate mechanisms, including static preconfiguration, DNS 1237 [22,27,44,45], BOOTP [18], DHCP [21], SLP [28], and others. Specific 1238 recommendations on use of these protocols in this environment can help 1239 foster common discovery methods across a range of access devices and 1240 ease configuration complexity. 1242 It was recommended to investigate standard methods to transport through 1243 the garden wall (e.g., escape to the Internet). It seemed clear that a 1244 better model is required than trying to map all access over a HTTP [23] 1245 transport connection gateway. One suggestion was to propose use of IP! 1247 4.3 Recommendations on IPv4 and IPv6 Scaling 1249 Wireless operators are projecting supporting on the order of 10's to 1250 100's million users on their Internet-based services. Supporting this 1251 magnitude of users could have severe scaling implications on use of the 1252 dwindling IPv4 address space. 1254 4.3.1 1256 There was clear consensus that any IPv4-based model relying on tradi- 1257 tional stateless NAT technology [60] is to be strongly discouraged. NAT 1258 has several inherent faults, including breaking the Internet peer-to- 1259 peer communication model, breaking end-to-end security, and stifling 1260 deployment of new services [16,29,31]. In addition, the state and per- 1261 formance implications of supporting 10's to 100's million users is cost 1262 and technologically prohibitive. 1264 4.3.2 1266 Realm specific IP (RSIP) [10,11] has potential to restore the end-to-end 1267 communication model in the IPv4 Internet, broken by traditional NAT. 1268 However there was considerable reluctance to formally recommend this as 1269 the long term solution. Detriments to its adoption include that the 1270 protocol is still being researched and defined, and potential interac- 1271 tions with applications, QoS features, and security remain. In addition, 1272 added signaling, state, and tunneling has cost and may be technologi- 1273 cally prohibitive scaling. 1275 4.3.3 1277 The clear consensus of the workshop was to recommend adoption of an 1278 IPv6-based solution to support these services requiring large scaling. 1279 Adoption of IPv6 will aid in restoring the Internet end-to-end communi- 1280 cation model and eliminates some roaming issues. Adoption of IPv6 in 1281 this marketspace could also help spur development of IPv6 products and 1282 applications, and hasten transition of the Internet. It was recognized 1283 that some application gateways are required during transition of the 1284 IPv4 Internet, however it was felt that the scaling and roaming benefits 1285 outweighed these issues. 1287 4.3.4 1289 It was recommended that an effort be made to eliminate any requirement 1290 for NAT in an IPv6 Internet. The IAB believes that the IPv6 address 1291 space is large enough to preclude any requirement for private address 1292 allocation [55] or address translation due to address space shortage 1293 [15]. Therefore, accomplishing this should primarily require installing 1294 and enforcing proper address allocation policy on registry and service 1295 providers. It was recommended to establish policies requiring service 1296 providers to allocate a sufficient quantity of global addresses for a 1297 sites use. The feeling was that NAT should be easily eliminated provided 1298 efficient strategies are defined to address renumbering [17,62] and 1299 mobility [37] issues. 1301 4.4 Recommendations on IPv4 and IPv6 Mobility 1303 An inherent characteristic of wireless systems is their potential for 1304 accommodating device roaming and mobility. Scalable and efficient sup- 1305 port of this mobility within Internet protocols can aid in pushing 1306 native IP services out to the mobile devices. 1308 4.4.1 1310 Several limitations were identified relating to current specification of 1311 mobile IPv4 [48]. Primary among these limitations is that mechanisms to 1312 support redundant home agents and failover are not currently defined. 1313 Redundant home agents are required to avoid single point of failure, 1314 which would require (proprietary) extensions. Additional deficiencies 1315 related to lack of route optimization, and tunneling and path MTU issues 1316 were also identified. Due to these limitations there was reluctance to 1317 recommend this as a solution. 1319 4.4.2 1321 It was recommended to encourage adoption of IPv6 mobility extensions 1322 [37] to support roaming capabilities in the wireless environment. IP 1323 mobility over IPv6 incorporates improvements to address several limita- 1324 tions of the IPv4-based mobility. The ability to use autoconfiguration 1325 for "care of" address improves robustness and efficiency. Additionally, 1326 path MTU is more easily adapted when a router forwards to a new "care 1327 of" address. 1329 Building wireless roaming atop IPv6-based mobility may introduce 1330 IPv4/IPv6 transition issues unique to the mobile environment. It was 1331 recommended to add investigation of these issues to the charter of the 1332 existing IETF Next Generation Transition (ngtrans) working group, pro- 1333 vided any mobile IP interoperation issues be identified. 1335 4.4.3 1337 Scalable and widespread authentication, authorization, and accounting 1338 (AAA) services are critical to the deployment of commercial services 1339 based on (wireless) mobile IP. Some work is progressing on definition of 1340 these standards for IP mobility [26,49]. However, due to the pivotal 1341 role of these protocols on the ability to deploy commercial services, it 1342 was recommended to make finalization of these AAA standards and investi- 1343 gation of AAA scalability as high priorities. 1345 4.5 Recommendations on TCP and Transport Protocols 1347 The wireless environment and applications place additional requirements 1348 on transport protocol. Unique link error and performance characteris- 1349 tics, and application sensitivity to connection setup and transaction 1350 semantics has led to "optimized" transports specific to each environ- 1351 ment. These new transports often lack robustness found in Internet 1352 transport and place barriers to seamless gatewaying to the Internet. It 1353 was felt that better education on transport design and cooperation on 1354 Internet transport evolution could lead to significant improvements. 1356 4.5.1 1358 It was recommended that the IETF Transport Area (tsv) working group doc- 1359 ument why Internet transport protocols are the way they are. The focus 1360 should be on generic transport issues and mechanisms, rather than TCP 1361 specifics. This should capture usage and tradeoffs in design of specific 1362 transport mechanisms (e.g., connection establishment, congestion con- 1363 trol, loss recovery strategies, etc.), and document some of the history 1364 behind transport research in the Internet. 1366 This "entry point" document into transport design is in direct support 1367 of the recommendations in section 4.1 to foster communication and mutual 1368 education. In addition it was deemed critical that the Internet commu- 1369 nity make it very clear that congestion control is not optional. Inter- 1370 net researchers have learned that optimizing for a single link or 1371 homogeneous environment does not scale. Early work by Jacobson [34,35], 1372 standardization of TCP congestion control [5], and continuing work 1373 within the IETF Endpoint Congestion Management (ecm) working group could 1374 provide excellent basis for education of wireless transport designers. 1376 4.5.2 1378 It was recommended that the IETF actively solicit input from external 1379 standards bodies on identifying explicit requirements and in assessing 1380 inefficiencies in existing transports in support of cellular and wire- 1381 less environments. This has proven highly effective in identifying 1382 research topics and in guiding protocol evolution to address new opera- 1383 tional environments, for instance in cooperation with groups doing 1384 satellite-based internetworking [4,6]. 1386 4.5.3 1388 It was recommended that the IAB make wireless standards bodies aware of 1389 the existence, and get them active in, the IETF Transport Area (tsv) 1390 working group. This transport "catch all" could provide an excellent 1391 forum for workers outside the Internet community to propose ideas and 1392 requirements, and engage in dialog with IESG members prior to contribut- 1393 ing any formal proposal into the IETF or incurring overhead of working 1394 group formation. 1396 4.5.4 1398 Mobile radio environments may often be subject to frequent temporary 1399 outages. For example, roaming through an area that is out of range of 1400 any base station, or disruptions due to base station handoffs. This vio- 1401 lation of the congestive loss assumption of TCP can have severe detri- 1402 mental effect on transport performance. It was recommended to investi- 1403 gate mechanisms for improving transport performance when these non-con- 1404 gestive loss can be detected. Areas for potential research identified 1405 include incorporation of "hints" to the sender providing Non-Congestive 1406 Loss Indication (NCLI) or stimulating transmission after link recovery 1407 via Source Encourage (SE) message [39]. This likely falls to the auspice 1408 of the IETF Performance Implications of Link Characteristics (pilc) 1409 working group. 1411 4.5.5 1413 Many wireless applications require transaction semantics and are highly 1414 sensitive to connection establishment delays (e.g., WAP). However, it 1415 is still desirable to efficiently support streaming of large bulk trans- 1416 fers too. It was recommended to investigate tradeoffs in supporting 1417 these transaction and streaming connections. Potential areas for inves- 1418 tigation include tradeoffs between minimal transaction transport and 1419 potential security and denial of service (DoS) attacks, mechanisms to 1420 piggyback data during connection establishment to eliminate round trip 1421 delays, or ways for endpoints to cooperate in eliminating setup hand- 1422 shake for simple transactions while providing switchover to reliable 1423 streaming for bulk transfers. 1425 4.5.6 1427 It was recommended to look at (TCP) transport improvements specific to 1428 the wireless and mobile environment. An example is to investigate reat- 1429 tachable transport endpoints. This could allow for graceful recovery of 1430 a transport connection after a roaming or mobility event results in 1431 changes to one or both endpoint identifiers. Another area for potential 1432 investigation is to develop targeted uses of D-SACK [25]. D-SACK pro- 1433 vides additional robustness to reordered packets, which may prove bene- 1434 ficial in wireless environment where packets are occasionally corrupted. 1435 Higher performance may be attainable by eliminating requirements on 1436 link-level retransmission maintaining in-order delivery within a flow. 1438 4.6 Recommendations on Routing 1440 Unique routing requirements may be introduced in support of wireless 1441 systems, especially when viewing the mobile component as an autonomous 1442 system (AS). 1444 4.6.1 1446 It was recommended that the IETF Routing Area commence investigation of 1447 extensions to the BGP protocol [54] to support additional policy fea- 1448 tures available within the ISO IDRP protocol [33]. The range of policy 1449 control desired includes adopting different identity or policies based 1450 on current point of attachment, and providing flexibility in path selec- 1451 tion based on local policy and/or current peer policy. These features 1452 could be used for instance in support of requirements established in the 1453 Aeronautical Telecommunication Network (ATN). 1455 4.6.2 1457 It was recommended that the IETF Routing Area commence investigation of 1458 extensions to the BGP protocol [54] to support additional QoS/TOS path 1459 selection features available within the ISO IDRP protocol [33]. The 1460 range of policies include differentiating service level or path selec- 1461 tion based on traffic classes. An example, based on Aeronautical 1462 Telecommunication Network (ATN) requirements, might be differentiating 1463 path selection and service between airline control and passenger enter- 1464 tainment traffic. 1466 4.7 Recommendations on Mobile Host QoS Support 1468 Wireless link bandwidth is often scarce (e.g., cellular) and/or shared 1469 (e.g., IEEE 802.11 WLAN). Meeting application QoS needs requires accom- 1470 modating these link characteristic, in addition to the roaming nature of 1471 mobile host. Specialized support may be required from the network layer 1472 to meet both link and end-to-end performance constraints. 1474 4.7.1 1476 It was recommended that the IETF Transport Area undertake investigation 1477 into providing QoS in the last leg of mobile systems. That is, between 1478 the mobile device and the network access point. This type of QoS support 1479 might be appropriate where the wireless link is the most constrained 1480 resource. A potential solution to investigate is to employ an explicit 1481 reservation mechanism between the mobile host and the access point 1482 (e.g., RSVP [13]), while relying on resource provisioning or more scal- 1483 able DiffServ [9] technologies within the core. 1485 4.7.2 1487 It was recommended that the IETF Transport Area undertake investigation 1488 into end-to-end QoS when the path includes a mixture of wireless and 1489 wired technologies. This investigation could focus on mechanism to com- 1490 municate QoS characteristics in cellular network to the core network to 1491 establish end-to-end QoS guarantees. An alternative investigation is to 1492 look into discovery problem of assessing current end-to-end performance 1493 characteristics, enabling for dynamic adaptation by mobile host. 1495 4.8 Recommendations on Application Mobility 1497 In a mobile environment with roaming, and mobile host disconnect and 1498 reconnect at different attachment point it may be desirable to recover 1499 an incomplete application session. It was recommended that the IRTF 1500 investigate application mobility at this level. The goal is to achieve a 1501 smooth recovery after a disconnect period; something more graceful than 1502 a "redial". Currently there does not appear to be sufficient information 1503 available within the network stack, this may require instantiation of 1504 some form of "session" layer. 1506 4.9 Recommendations on TCP/IP Performance Characterization in WAP-like 1507 Environment 1509 WAPF has gone to considerable effort to develop unique transport proto- 1510 col and optimizations due to perception that TCP/IP protocol stack is 1511 too expensive. Much of this was predicated on WAP requirements to sup- 1512 port very low datarate bearer services. It was recommended that members 1513 of the IRTF evaluate TCP/IP stack performance in WAP-like environment to 1514 quantify its behavior and applicability. The focus should include 1515 investigation of code and memory space requirements, as well as link 1516 usage to complete a single transaction for current WAP protocols and for 1517 both IPv4 and IPv6. This work should result in better characterization 1518 of TCP/IP performance in highly constrained devices and network, recom- 1519 mendations to the IETF on protocol enhancements to optimize performance 1520 in this environment, and recommendations to WAPF on suitability of 1521 deploying native IP protocols. 1523 4.10 Recommendations on Protocol Encoding 1525 IETF protocol developments have traditionally taken the approach of pre- 1526 ferring simple encode/decode and word alignment at the cost of some 1527 extra bit transmissions. This overhead may prove too burdensome in some 1528 bandwidth constrained environments, such as cellular wireless and WAP. 1529 Work within the IETF Robust Header Compression (rohc) working group may 1530 go a long way to reducing some of these detriments to Internet protocols 1531 deployment. However, there may be potential for additional savings from 1532 investigation of alternative encoding of common Internet protocols. It 1533 was recommended that members of the IRTF evaluate general techniques 1534 that can be used to reduce protocol "verbiage". Examples might include 1535 payload compression techniques or tokenized protocol encoding. 1537 4.11 Recommendations on Inter-Domain AAA Services 1539 Commercial roaming and mobility services are likely to require exchange 1540 of authentication, authorization, and billing services spanning multiple 1541 domains (service providers). This introduces requirements related to 1542 establishing a web or hierarchy of trust across multiple autonomous 1543 domains. Standard protocols to specify and exchange usage policies and 1544 billing information must also be established. Some work is progressing 1545 on scoping out the issues and a framework [7,64]. However, there are 1546 significant issues to be solved to enable a scalable, Internet-wide 1547 solution. Due to the pivotal role of these protocols on the ability to 1548 deploy commercial services, it was recommended to make finalization of 1549 scalable inter-domain AAA as high priority within the IETF. 1551 4.12 Recommendations on Bluetooth 1553 Bluetooth protocols and devices were originally optimized for a narrow 1554 application space. However, there is interest in exploring the breadth 1555 to which protocol and device access can be extended. One particular area 1556 of interest is exploring integration into, or gatewaying access to, the 1557 Internet. It was recommended that the IETF pursue formation of a joint 1558 BOF to assemble experts from the IETF and Bluetooth communities to begin 1559 exploration of this problem. This is in direct support of the recommen- 1560 dations in section 4.1 to foster communication and mutual education. 1562 4.13 Recommendations on Proxy Architecture 1564 Proxy agents are often deployed to intercept and evaluate protocol 1565 requests (e.g., web cache, HTTP redirector, filtering firewall) or to 1566 gateway access between communication domains (e.g., traversing bastion 1567 host between private network and Internet or gatewaying between a cellu- 1568 lar service and the Internet). There are a number of potential architec- 1569 tures when contemplating development and deployment of one of these 1570 proxy agent. It was recommended that members of the IRTF investigate 1571 taxonomy of proxy architectures and evaluate their characteristics and 1572 applicability. Each type of proxy should be characterized, for example, 1573 by its effect on Internet end-to-end model, and security, scaling, and 1574 performance implications. The results of this study can help educate 1575 developers and network operators on the range of proxy available and 1576 recommend solutions that are least disruptive to Internet protocols. 1578 4.14 Recommendations on Justifying IPv6-based Solutions for Mobile / 1579 Wireless Internet 1581 IPv6 was strongly recommended to address scaling (see section 4.3) and 1582 mobility (see section 4.4) issues in the future Internet dominated by 1583 large numbers of wireless and mobile devices. It was recommended that 1584 the IAB draft a formalized justification for these recommendations for 1585 adoption of IPv6-based solution. It was believed that the "The Case for 1586 IPv6" [40] document should form an excellent basis for this justifica- 1587 tion. In addition, documents highlighting architectural and operational 1588 pitfalls of continued reliance on IPv4 and NAT also provide excellent 1589 justification [29,31,59]. It was deemed urgent to submit these informa- 1590 tional documents as inputs to other standards bodies (MWIF, 3GPP, 1591 3G.IP), as many decisions are being made on Internet protocol adoption 1592 and this data could be highly influential. 1594 5 Security Considerations 1596 This workshop did not focus on security. However, mobility and wireless 1597 environment introduces additional complexities for security and poten- 1598 tial attacks to user authentication and privacy. The presentations by 1599 Asokan and by Calhoun referenced in section 2 focused on security mecha- 1600 nisms in currently deployed cellular networks and evolution toward 3G 1601 cellular and IP networks. Discussion on the "walled garden" service 1602 model (see section 3.1) briefly mentions effects on simplifying security 1603 requirements. Section 3.3 raises a number of security issues related to 1604 wireless devices and mobility. These include alternatives for establish- 1605 ing user identity and capabilities, securing network infrastructure from 1606 attacks, and security associations required for mobile IP and AAA opera- 1607 tion. Section 3.7 mentions interoperation issues between compression 1608 and encryption or tunneling, and finally section 3.9 highlight potential 1609 for proxy agent to be used to offload expensive crypto operations. 1611 6 Acknowledgments 1613 The author would like to thank all of the workshop participants for 1614 their feedback, encouragement, and patience during the writeup of this 1615 document. I would especially like to thank Brian Carpenter for prompt 1616 responses to questions on the document organization and content. Simi- 1617 larly, Charlie Perkins provided extensive feedback that dramatically 1618 improved and corrected statements throughout the report. Finally, Mikael 1619 Degermark, Sally Floyd, Heikki Hammainen, Geoff Huston, and Gabriel Mon- 1620 tenegro contributed comments and responses to questions. 1622 7 Bibliography 1624 [1] ACIRI. TCP-Friendly Rate Control. http://www.aciri.org/tfrc. 1626 [2] A. Aggarwal, S. Savage, and T. Anderson. Understanding the Perfor- 1627 mance of TCP Pacing. Proceedings of IEEE Infocom 2000, March 2000. 1629 [3] M. Allman, S. Floyd, and C. Partridge. Increasing TCP's Initial 1630 Window. Internet Request for Comments, RFC-2414, September 1998. 1632 [4] M. Allman, D. Glover, and L. Sanchez. Enhancing TCP Over Satellite 1633 Channels using Standard Mechanisms. Internet Request for Comments, 1634 RFC-2488, January 1999. 1636 [5] M. Allman, V. Paxson, and W. Stevens. TCP Congestion Control. 1637 Internet Request for Comments, RFC-2581, April 1999. 1639 [6] M. Allman, et al. Ongoing TCP Research Related to Satellites. 1640 Internet Request for Comments, RFC-2760, February 2000. 1642 [7] J. Arkko. Requirements for Internet-Scale Accounting Management. 1643 Internet Draft, draft-arkko-acctreqlis-00.txt, August 1998 (work in 1644 progress). 1646 [8] T. Bates, R. Chandra, D. Katz, and Y. Rekhter. Multiprotocol Exten- 1647 sions for BGP-4. Internet Request for Comments, RFC-2283, February 1648 1998. 1650 [9] S. Blake, et al. An Architecture for Differentiated Services. 1651 Internet Request for Comments, RFC-2475, December 1998. 1653 [10] M. Borella, et al. Realm Specific IP: Framework. Internet Draft, 1654 draft-ietf-nat-rsip-framework-04.txt, March 2000 (work in progress). 1656 [11] M. Borella, et al. Realm Specific IP: Protocol Specification. 1657 Internet Draft, draft-ietf-nat-rsip-protocol-06.txt, March 2000 (work in 1658 progress). 1660 [12] R. Braden. T/TCP -- TCP Extensions for Transactions Functional 1661 Specification. Internet Request for Comments, RFC-1644, July 1994. 1663 [13] R. Braden, et al. Resource ReSerVation Protocol (RSVP) -- Version 1664 1 Functional Specification. Internet Request for Comments, RFC-2205, 1665 September 1997. 1667 [14] S. Brim, B. Carpenter, and F Le Faucheur. Per Hop Behavior Identi- 1668 fication Codes. Internet Request for Comments, RFC-2836, May 2000. 1670 [15] B. Carpenter, J. Crowcroft, and Y. Rekhter. IPv4 Address Behaviour 1671 Today. Internet Request for Comments, RFC-2101, February 1997. 1673 [16] B. Carpenter. Internet Transparency. Internet Request for Com- 1674 ments, RFC-2775, February 2000. 1676 [17] M. Crawford. Router Renumbering for IPv6. Internet Draft, draft- 1677 ietf-ipngwg-router-renum-10.txt, March 2000 (work in progress). 1679 [18] B. Croft and John Gilmore. Bootstrap Protocol (BOOTP). Internet 1680 Request for Comments, RFC-951, September 1985. 1682 [19] S. Deering and R. Hinden. Internet Protocol, Version 6 (IPv6) 1683 Specification. Internet Request for Comments, RFC-2460, December 1998. 1685 [20] T. Dierks and C. Allen. The TLS Protocol Version 1.0. Internet 1686 Request for Comments, RFC-2246, January 1999. 1688 [21] R. Droms. Dynamic Host Configuration Protocol. Internet Request 1689 for Comments, RFC-2131, March 1997. 1691 [22] C. Everhart, et al. New DNS RR Definitions. Internet Request for 1692 Comments, RFC-1183, October 1990. 1694 [23] R. Fielding, et al. Hypertext Transfer Protocol -- HTTP/1.1. 1695 Internet Request for Comments, RFC-2616, June 1999. 1697 [24] S. Floyd and T. Henderson. The NewReno Modification to TCP's Fast 1698 Recovery Algorithm. Internet Request for Comments, RFC-2582, April 1699 1999. 1701 [25] S. Floyd, et al. An Extension to the Selective Acknowledgment 1702 (SACK) Option for TCP. Internet Draft, draft-floyd-sack-00.txt, Febru- 1703 ary 2000 (work in progress). 1705 [26] S. Glass, et al. Mobile IP Authentication, Authorization, and 1706 Accounting Requirements. Internet Draft, draft-ietf-mobileip-aaa- 1707 reqs-03.txt, March 2000 (work in progress). 1709 [27] A. Gulbrandsen and P. Vixie. A DNS RR for specifying the location 1710 of services (DNS SRV). Internet Request for Comments, RFC-2052, October 1711 1996. 1713 [28] E. Guttman, et al. Service Location Protocol, Version 2. Internet 1714 Request for Comments, RFC-2608, June 1999. 1716 [29] T. Hain. Architectural Implications of NAT. Internet Draft, 1717 draft-iab-nat-implications-05.txt, February 2000 (work in progress). 1719 [30] M. Handley, et al. SIP: Session Initiation Protocol. Internet 1720 Request for Comments, RFC-2543, March 1999. 1722 [31] M. Holdrege and P. Srisuresh. Protocol Complications with the IP 1723 Network Address Translator (NAT). Internet Draft, draft-ietf-nat-proto- 1724 col-complications-02.txt, March 2000 (work in progress). 1726 [32] International Telecommunication Union. Visual Telephone Systems 1727 and Equipment for Local Area Networks which provide a Non-guaranteed 1728 Quality of Service. Recommendation H.323, May 1996. 1730 [33] ISO/IEC. Protocol for Exchange of Inter-Domain Routeing Informa- 1731 tion among Intermediate Systems to support Forwarding of ISO 8473 PDUs. 1732 ISO/IEC IS10747, 1993. 1734 [34] V. Jacobson. Congestion Avoidance and Control. Computer Communi- 1735 cation Review, vol. 18, no. 4 August 1988. 1736 ftp://ftp.ee.lbl.gov/papers/congavoid.ps.Z. 1738 [35] V. Jacobson. Modified TCP Congestion Avoidance Algorithm. 1739 end2end-interest mailing list, April 30, 1990. 1740 ftp://ftp.isi.edu/end2end/end2end-interest-1990.mail. 1742 [36] V. Jacobson, R. Braden, and D. Borman. TCP Extensions for High 1743 Performance. Internet Request for Comments, RFC-1323, May 1992. 1745 [37] D. Johnson and C. Perkins. Mobility Support in IPv6. Internet 1746 Draft, draft-ietf-mobileip-ipv6-12.txt, April 2000 (work in progress). 1748 [38] L. Jonsson, et al. RObust Checksum-based header COmpression 1749 (ROCCO). Internet Draft, draft-ietf-rohc-rtp-rocco-00.txt, May 2000 1750 (work in progress). 1752 [39] P. Karn, et al. Advice for Internet Subnetwork Designers. Inter- 1753 net Draft, draft-ietf-pilc-link-design-02.txt, March 2000 (work in 1754 progress). 1756 [40] S. King, et al. The Case for IPv6. Internet Draft, draft-iab- 1757 case-for-ipv6-05.txt, October 1999 (work in progress). 1759 [41] J. Kulik, R. Coulter, D. Rockwell, and C. Partridge. Paced TCP for 1760 High Delay-Bandwidth Networks. Proceedings of IEEE Globecom '99, Decem- 1761 ber 1999. 1763 [42] K. Le, et al. Adaptive Header ComprEssion (ACE) for Real-Time Mul- 1764 timedia. Internet Draft, draft-ietf-rohc-rtp-ace-00.txt, May 2000 (work 1765 in progress). 1767 [43] M. Mathis, J. Mahdavi, S. Floyd, and A. Romanow. TCP Selective 1768 Acknowledgment Options. Internet Request for Comments, RFC-2018, Octo- 1769 ber 1996. 1771 [44] P. Mockapetris. Domain Names -- Concepts and Facilities. Internet 1772 Request for Comments, RFC-1034, STD0013, November 1987. 1774 [45] P. Mockapetris. Domain Names -- Implementation and Specification. 1775 Internet Request for Comments, RFC-1035, STD0013, November 1987. 1777 [46] K. Nichols, S. Blake, F. Baker, and D. Black. Definition of the 1778 Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers. 1779 Internet Request for Comments, RFC-2474, December 1998. 1781 [47] C. Partridge, T. Mendez, and W. Milliken. Host Anycasting Service. 1782 Internet Request for Comments, RFC-1546, November 1993. 1784 [48] C. Perkins. IP Mobility Support. Internet Request for Comments, 1785 RFC-2002, October 1996. 1787 [49] C. Perkins and P. Calhoun. AAA Registration Keys for Mobile IP. 1788 Internet Draft, draft-ietf-mobileip-aaa-key-01.txt, January 2000 (work 1789 in progress). 1791 [50] C. Perkins and D. Johnson. Route Optimization in Mobile IP. 1792 Internet Draft, draft-ietf-mobileip-optim-09.txt, February 2000 (work in 1793 progress). 1795 [51] J. Postel. User Datagram Protocol. Internet Request for Comments, 1796 RFC-768, STD0006, August 1980. 1798 [52] J. Postel. Internet Protocol. Internet Request for Comments, 1799 RFC-791, STD0005, September 1981. 1801 [53] K. Ramakrishnan and S. Floyd. A Proposal to add Explicit Conges- 1802 tion Notification (ECN) to IP. Internet Request for Comments, RFC-2481, 1803 January 1999. 1805 [54] Y. Rekhter and T. Li. A Border Gateway Protocol 4 (BGP-4). Inter- 1806 net Request for Comments, RFC-1771, March 1995. 1808 [55] Y. Rekhter, et al. Address Allocation for Private Internets. 1809 Internet Request for Comments, RFC-1918, BCP0005, February 1996. 1811 [56] C. Rigney, A. Rubens, W. Simpson, and S. Willens. Remote Authenti- 1812 cation Dial In User Service (RADIUS). Internet Request for Comments, 1813 RFC-2138, April 1997. 1815 [57] H. Schulzrinne, et al. RTP: A Transport Protocol for Real-Time 1816 Applications. Internet Request for Comments, RFC-1889, January 1996. 1818 [58] J. Semke, J. Mahdavi, and M. Mathis. Automatic TCP Buffer Tuning. 1819 Proceedings of ACM SIGCOMM '98, September 1998. 1821 [59] P. Srisuresh and M. Holdrege. IP Network Address Translator (NAT) 1822 Terminology and Considerations. Internet Request for Comments, 1823 RFC-2663, August 1999. 1825 [60] P. Srisuresh and K. Egevang. Traditional IP Network Address Trans- 1826 lator (Traditional NAT). Internet Draft, draft-ietf-nat-tradi- 1827 tional-04.txt, April 2000 (work in progress). 1829 [61] R. Steward, et al. Stream Control Transmission Protocol. Internet 1830 Draft, draft-ietf-sigtran-sctp-09.txt, April 2000 (work in progress). 1832 [62] S. Thomson and T. Narten. IPv6 Stateless Address Autoconfigura- 1833 tion. Internet Request for Comments, RFC-2462, December 1998. 1835 [63] J. Touch. TCP Control Block Interdependence. Internet Request for 1836 Comments, RFC-2140, April 1997. 1838 [64] J. Vollbrecht, et al. AAA Authorization Framework. Internet 1839 Draft, draft-ietf-aaa-authz-arch-00.txt, October 1999 (work in 1840 progress). 1842 A Participants 1844 Juha Ala-Laurila JUHA.ALA-LAURILA@nokia.com 1845 Mark Allman mallman@grc.nasa.gov 1846 Alastair Angwin angwin@uk.ibm.com 1847 N. Asokan n.asokan@nokia.com 1848 Victor Bahl bahl@microsoft.com 1849 Fred Baker fred@cisco.com 1850 Pravin Bhagwat pravinb@us.ibm.com 1851 Scott Bradner sob@harvard.edu 1852 Randy Bush randy@psg.com 1853 Pat Calhoun Pcalhoun@eng.sun.com 1854 Brian Carpenter brian@icair.org 1855 Mikael Degermark micke@cs.arizona.edu 1856 Sally Floyd floyd@aciri.org 1857 Heikki Hammainen HEIKKI.HAMMAINEN@NOKIA.COM 1858 Mark Handley mjh@aciri.org 1859 Bob Hinden hinden@iprg.nokia.com 1860 Christian Huitema huitema@microsoft.com 1861 Chih-Lin I ci@att.com 1862 Van Jacobson van@packetdesign.com 1863 Phil Karn Karn@qualcomm.com 1864 John Klensin Klensin@JCK.com 1865 Jerry Lahti jerry.lahti@nokia.com 1866 Allison Mankin mankin@isi.edu 1867 Danny J. Mitzel mitzel@iprg.nokia.com 1868 Gabriel Montenegro gab@sun.com 1869 Keith Moore moore@cs.utk.edu 1870 Eric Nordmark nordmark@sun.com 1871 Charles E. Perkins charliep@iprg.nokia.com 1872 Jonne Soininen jonna.Soininen@nokia.com 1873 Chris A. Wargo cwargo@cnsw.com 1874 Lars Westberg Lars.Westberg@era.ericsson.se 1875 Lixia Zhang lixia@cs.ucla.edu 1877 B Author's Address 1879 Danny J. Mitzel 1880 Nokia 1881 313 Fairchild Drive 1882 Mountain View, CA 94043 1883 USA 1884 Phone: +1 650 625 2037 1885 Email: mitzel@iprg.nokia.com 1887 C Changes from draft-iab-wirelessws-00.txt 1889 + incorporated fixes for mostly minor grammatical errors and some 1890 statement clarifications throughout the draft. these affect many 1891 subsections of both discussion and recommendations, but no sub- 1892 stantive changes to document recommendations. 1894 + incorporated comments from geoff huston on non-congestive loss 1895 indication in section 3.4. mostly adding discussion on general 1896 mechanism to more closely tie layer 2 (link layer) status signal- 1897 ing to TCP transport operation. 1899 + renamed routing policy discussion section (section 3.5) to "Dis- 1900 cussion on Aeronautical Telecommunication Network (ATN) Routing 1901 Policy" to indicate its primary focus on ATN routing require- 1902 ments. 1904 + slight wording changes to routing recommendations in section 4.6. 1905 rather than targeting ATN explicitly, state recommendations as 1906 embellishing BGP to provide additional IDRP-like capabilities, 1907 with ATN as potential consumer of such new features. 1909 + added "Acknowledgments" section (section 6). 1911 + added some extra hacks to document build process to warp table of 1912 contents up to front of document.