RFC 3002

Overview of 2000 IAB Wireless Internetworking Workshop

📅 published December 2000, from ietf

Part 1 of 9 💖

RFC 3002: Overview of 2000 IAB Wireless Internetworking Workshop 📜

Okay bestie, this one is an Informational doc from December 2000, written by D. Mitzel at Nokia for the Network Working Group 🎀. Informational means it's sharing info with the Internet community, not setting a standard. The title block doesn't list anything it obsoletes or updates, so it's a standalone recap ✨.

Status of This Memo 🌸

This memo gives information to the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.

Copyright (C) The Internet Society (2000). All Rights Reserved.

Abstract 🦋

Okay so this doc is a recap of a workshop the Internet Architecture Board (IAB) hosted on wireless internetworking. Nokia hosted it in Mountain View, CA, USA, on February 29 thru March 2, 2000 🌈. The vibe was to figure out how Internet tech is being used in wireless land right now and where it's headed, make recommendations on research and standards work so Internet network and transport protocols get more love in wireless environments, and find better ways for Internet standards groups to talk to the telephony and wireless crowds 🫶. The doc sums up the IAB's conclusions and recommendations on behalf of the IETF community 👑.

Comments should be submitted to the IAB-Wireless-Workshop@ietf.org mailing list 💜.

Table of Contents 📚

1      Introduction  . . . . . . . . . . . . . . . . . . . .   3
2      Presentation Overview . . . . . . . . . . . . . . . .   4
3      Discussion and Observations . . . . . . . . . . . . .   9
3.1    Discussion on "Walled Garden" Service Model . . . . .   9
3.2    Discussion on Mobility and Roaming  . . . . . . . . .  10
3.2.1  Discussion on Mobility and Roaming Model  . . . . . .  11
3.2.2  Discussion on Mobility and Roaming Protocols  . . . .  11
3.2.3  Discussion on Mobility and Roaming Services . . . . .  12
3.3    Discussion on Security Model  . . . . . . . . . . . .  12
3.3.1  Discussion on User Identity . . . . . . . . . . . . .  12
3.3.2  Discussion on WAP Security  . . . . . . . . . . . . .  13
3.3.3  Discussion on 3G Network Security . . . . . . . . . .  13
3.4    Discussion on Transports  . . . . . . . . . . . . . .  14
3.4.1  Discussion on Link Characteristics and Mobility
       Effect on Transport . . . . . . . . . . . . . . . . .  14
3.4.2  Discussion on WAP Transport . . . . . . . . . . . . .  16
3.4.3  Discussion on IETF Transport Activities . . . . . . .  16
3.5    Discussion on Aeronautical Telecommunication Network
       (ATN) Routing Policy. . . . . . . . . . . . . . . . .  17
3.6    Discussion on QoS Services  . . . . . . . . . . . . .  18
3.6.1  Discussion on "Last Leg" QoS  . . . . . . . . . . . .  18
3.6.2  Discussion on Path QoS Discovery  . . . . . . . . . .  19
3.7    Discussion on Header Compression  . . . . . . . . . .  20
3.8    Discussion on Applications Protocols  . . . . . . . .  21
3.9    Discussion on Proxy Agents  . . . . . . . . . . . . .  22
3.10   Discussion on Adoption of IPv6  . . . . . . . . . . .  22
3.11   Discussion on Signaling . . . . . . . . . . . . . . .  23
3.12   Discussion on Interactions Between IETF and Other
       Standards Organizations . . . . . . . . . . . . . . .  24
4      Recommendations . . . . . . . . . . . . . . . . . . .  25
4.1    Recommendations on Fostering Interaction with Non-
       Internet Standards Organizations  . . . . . . . . . .  25
4.2    Recommendations for Dealing with "Walled Garden"
       Model . . . . . . . . . . . . . . . . . . . . . . . .  26
4.3    Recommendations on IPv4 and IPv6 Scaling  . . . . . .  27
4.4    Recommendations on IPv4 and IPv6 Mobility . . . . . .  28
4.5    Recommendations on TCP and Transport Protocols  . . .  29
4.6    Recommendations on Routing  . . . . . . . . . . . . .  31
4.7    Recommendations on Mobile Host QoS Support  . . . . .  32
4.8    Recommendations on Application Mobility . . . . . . .  33
4.9    Recommendations on TCP/IP Performance Characterization
       in WAP-like Environment . . . . . . . . . . . . . . .  33
4.10   Recommendations on Protocol Encoding  . . . . . . . .  33
4.11   Recommendations on Inter-Domain AAA Services  . . . .  34
4.12   Recommendations on Bluetooth  . . . . . . . . . . . .  34
4.13   Recommendations on Proxy Architecture . . . . . . . .  34
4.14   Recommendations on Justifying IPv6-based Solutions for
       Mobile / Wireless Internet  . . . . . . . . . . . . .  35
5      Security Considerations . . . . . . . . . . . . . . .  35
6      Acknowledgments . . . . . . . . . . . . . . . . . . .  35
7      Bibliography  . . . . . . . . . . . . . . . . . . . .  36
A      Participants  . . . . . . . . . . . . . . . . . . . .  41
B      Author's Address  . . . . . . . . . . . . . . . . . .  41
       Full Copyright Statement  . . . . . . . . . . . . . .  42

1. Introduction 🌟

Okay, wireless tech is blowing up 💥. We've got wireless LANs, data over cellular radio (GSM, 3GPP, etc), and mobile stuff from aircraft and near-earth spacecraft ✈️🛰️. Some market projections say a mobile Internet, running alongside or boosting the wired one, could be about the same size as the wired Internet as early as 2003 🤯.

Here's the tea though 🍵. Wireless operators haven't gone with IPv4, TCP, full HTTP/HTML, and other apps, and there are a bunch of reasons: edge device cost, bandwidth limits, protocol imperfections people have noticed, unnecessary complexity, how chatty the application protocols are, and network layer addressing issues 🙈. Unfortunately that causes some serious drama at the wired/wireless border. End-to-end operation gets sacrificed, security gets compromised, and automated content modification ends up being necessary in some form 😭. The IAB says these are serious fundamental issues that will eventually become a big blocker for the combined Internet if nobody deals with them 🚨.

The Internet Architecture Board (IAB) held an invitational workshop on wireless internetworking from February 29 thru March 2, 2000 🎀. The goal was to assess current and future uses of Internet tech in wireless environments, make recommendations on research and standardization tasks to help Internet network and transport protocols get more accepted in wireless environments, and figure out ways for Internet standards working groups and the telephony and wireless sectors to communicate and collaborate better 🫶.

The workshop defined these topics for discussion 💜:

  • Local area wireless technologies
  • Cellular wireless technologies
  • Wireless Application Protocol (WAP)
  • Near-space and aviation wireless applications
  • Voice over IP (VoIP) over wireless networks
  • Security over wireless networks
  • Transport and QoS over wireless networks
  • Use of WWW protocols over wireless and small screen devices
  • Addressing requirements for wireless devices
  • Compression and bit error requirements for wireless networks

The big question they tackled was 🧠✨: "what are the issues, and what really needs to be done to unify the Internet below the application layer." Applications also need attention, but people felt that was too much for a three-day workshop and needs different expertise anyway 💅.

Section 2 gives a quick rundown of each presentation at the workshop, with references to more detailed materials 📚. Section 3 goes deeper into the major discussion topics 🦋. Section 4 covers the recommendations made to wireless operators, IRTF, and IETF about the architectural roadmap for the next few years 🗺️. Heads up, not every participant agreed with every statement, and it wasn't clear whether anyone agreed with all of them 🙈. Still, the recommendations are based on strong consensus among the participants 🫶. Last bits: section 5 highlights the security considerations that came up, appendix A lists contact info for workshop participants, and appendix B lists the author's contact info 🌈.

2 Presentation Overview ✨

Okay bestie, the workshop had a whole lineup of talks, so here's the full roster 🎀 Each one has a title, a presenter, and where to find the slides. I've kept every link exactly as it was published.

3 Discussion and Observations 💜

Now for the good part, the stuff everyone actually argued about 🍓 During the workshop a bunch of issues came up and people made observations. Sections 3.1 through 3.12 sum these up, but instead of going talk by talk, they're grouped by common "themes" and issues, which honestly makes way more sense ✨

3.1 Discussion on "Walled Garden" Service Model

Okay so the folks from the cellular side (3GPP, 3G.IP, MWIF) and the WAP world showed right away that their protocol specs and service models are super different from what the Internet crowd usually assumes 👀 Their whole thing is defining a profile (a set of protocols and operational parameters that work together) to deliver a well-defined user service. On top of that, carriers usually want as much control as possible over the entire service: the user's access device, the transmission facilities, and the service "content" 💅 This style seems to be inherited from the classic telephony provider model. The term "walled garden" was coined to describe the resulting captive customer economic and service model. So basically, the user is kept inside the limits of what the carrier provides, with limited ability to extend features or reach services outside the provider 🧱

The "walled garden" service model is in total contrast to the "open" service assumed in the Internet. In the Internet, the application, access device, and service content may each be controlled by a different entity, and the service provider is usually seen as little more than a "bit pipe" 🫧

Specifications also typically define a standalone protocol or application, rather than the whole set of features and interoperation with other components that you need to deploy a commercial service 🤓

Some discussion focused on whether cellular carriers could be persuaded to move toward the Internet's "open" service model. The answer was basically no. Carriers will always fight being reduced to a "bit pipe," because they fear they can't keep up their revenues without value-added services 😭 Another point was that the closed "walled garden" model simplifies a bunch of issues, like security, authorization, and billing, when the entire network is considered secured and controlled under a single administration. These simplifications can remove roadblocks to deploying services before scalable, interdomain solutions are available 🌈

Even though carriers aren't likely to leave the "walled garden" behind in the short term, recognizing it was still super valuable. This led to observations that "walled garden" Internet-based services will operate somewhat like current intranet services. It also led to the idea that mechanisms should be investigated to simplify interoperation and controlled access to the Internet. Finally, the difference between Internet protocol specification and service profiles highlights some of the confusion people in the telephony environment run into when they try to incorporate Internet capabilities 🎀

Much of the current work on extending Internet-based services to cellular customers has focused on data services such as email or web access. One observation about carriers' reluctance to release any control over services was that this may be an impediment to adopting Internet-based voice services 📞 Current work on voice over IP (VoIP) and call signaling (SIP [30]) loosens control over these services. Much of the functionality moves into the SIP agent, and the carrier is reduced to an access provider (i.e., "bit pipe") 🦋

3.2 Discussion on Mobility and Roaming

Wireless systems naturally have the potential to accommodate device roaming and mobility, so this came up a lot 🌸 Some discussion focused on the model of mobility presented to the user. There was also serious interest and debate about the protocols used, whether cellular telephony-based or IP-based. And finally, a few people wanted to explore new services enabled by mobility 🧚

3.2.1 Discussion on Mobility and Roaming Model

This was a big one, bestie 😤 There was considerable discussion and concern over what style of mobility and roaming needs to be supported. Current usage on the Internet is dominated by a mode where a user does some things at one location, then shuts down and moves, and restarts at a new location 💻

3G.IP uses the term "macro mobility" to describe this mode 🏷️

The group tried to figure out whether the current mode of usage is just a perceived limitation introduced by current protocols. A clear consensus could not be reached 🤷‍♀️ Everyone agreed that introducing this "macro mobility" roaming is a worthwhile first step. But that was immediately followed by questions about whether it's a sufficient first step, plus a warning not to stop at this level 🚦 There seem to be significant issues still to investigate, like enabling continual usage of a device while roaming ("micro mobility") and the ability to retrieve previous connections after a roaming event 💜

3.2.2 Discussion on Mobility and Roaming Protocols ✨

Okay so, the next big fight was about which protocols should handle roaming, cellular or IP 💅. Cellular operators already have roaming protocols that are seriously strong, so efforts like 3GPP and 3G.IP are pushing an architecture that relies on the telephone system for all mobility support. That basically hides roaming from the IP layer 🙈.

People who liked cellular-based roaming were mostly worried about the mobile IP model 😬. Their concerns were that the home agent and foreign agent could become a bottleneck in delivery, and that mobile IP handoff seems too slow. The rebuttal was that the IETF mobileip working group is adding hierarchy and route optimization to improve performance and robustness [50]. People still disagreed about whether mobile IP handoff is actually slow, so that one's not settled 🤷‍♀️.

The downsides of cellular-based roaming are the lack of IP support all the way out to the mobile device, plus the extra tunneling protocols and overhead it needs 💀. Roaming is also less well defined when you cross service provider boundaries, and it can end up with a highly non-optimal forwarding path. There's still a lot of work to do before everyone agrees, and more investigation is needed to support roaming across cellular, WLAN, and IP boundaries 🌈.

3.2.3 Discussion on Mobility and Roaming Services 🦋

The 3G.IP mobility model is mainly about giving ubiquitous service across a range of access media 📱. But the presenters also wanted to build new "location based" services. Their examples included finding nearby services, or getting ads and solicitations from businesses close by 📍.

There are several Internet protocols already defined, like anycast service [47] and SLP [28], that might help build location based services 🧚. The 3G.IP folks were pretty frustrated, though, because these protocols get little commercial support. Even worse, there's barely any direction on how to put together and coordinate the protocols you'd need to deploy the services they want 😤.

This exchange showed the disconnect between reading Internet standards and telephony service profiles 🎀. First, on the Internet many protocols are defined, but a lot of them are optional. Support usually follows market demand, and that can turn into a "chicken and egg" problem 🐣. Second, individual protocols and applications get developed, rather than a complete profile that combines them into a commercial service. For this service, looking at how service discovery protocols are used and how well they scale still seems like an open area for more investigation 🔍.

3.3 Discussion on Security Model 🔐

Mobility and wireless environments bring a lot of complexity and potential attacks on user authentication and privacy 😱. Besides the discussion below, there was a big overall statement about the methodology that has to be followed for all security protocol development. People felt very strongly that the only real chance of success is defining the protocols in a public forum, with full disclosure of all algorithms and thorough review by security experts 🫶. Put another way, defining protocols in a closed forum that relies on cellphone manufacturers, or other people who aren't experts on IP security, is very likely to create security exposures 🚨.

3.3.1 Discussion on User Identity 🪪

Where user identity is stored can have a big effect on device usage and device portability 📲. The discussion focused on whether identity should be tied to the mobile device or to a transferable SIM card. Fixing identity to the device might simplify manufacturing and provide some tamper resistance 🛡️. But it makes it very hard to deploy a public device that takes on the identity of the user. These alternatives also affect how identity and configuration state get transferred when a device is replaced or upgraded 🔄.

A related topic is that users want to use a single device but take on different identities and privileges depending on what they're doing at the moment, like getting corporate access, home access, or Internet access 💼🏠. How easily you can take on these multiple identities may depend a lot on the model of identity integration we just talked about. The discussion pointed out pitfalls with tying device and user identities together 🙃. IPsec's use of the device IP address gets in the way of roaming, because the address may change based on location, and it also stops you from separating identity and capabilities for the current usage. IPsec needs extra work to support this added flexibility 🧩.

The last identity question was whether having the device is enough, or whether the user should also have to authenticate to the device 🤔. In the real world, the first option looks like the credit card model, and the second is more like an ATM card, where the user also has to enter a PIN code 💳. Both models seem useful in the real world, and it's likely both will get used in wireless networking 💖.

3.3.2 Discussion on WAP Security 📡

WAP wireless transport security (WTLS) is based on TLS [20], with an optimized handshake so keys can be exchanged often 🔑. The security service uses a "vertical" integration model, with protocol components all the way through the network stack 🏗️. Some people argued that this is the wrong model. A better approach might have been a security layer with well defined interfaces 🧱. That could allow later tradeoffs among different protocols, driven by market, applications, and device capabilities ⚖️.

Other statements argued that the WAP security model shows the dangers of optimizing for a limited usage domain (the "walled garden") 🌷. Content provider systems that need security, like banks, have to deploy a special WAP proxy, and that breaks the model of a single WAP "domain" 💔. Similar issues come with gatewaying to the Internet too 🌐.

3.3.3 Discussion on 3G Network Security 🛰️

The existing GSM/GPRS model uses long term shared secrets (embedded in the SIM card) with one-way authentication to the network, and privacy is only provided on the access link 🔐. This is an example where the "walled garden" service model has an advantage 🏰. Having complete control over the service access devices and the network greatly reduces the range of security concerns and potential attacks 👑.

Future 3GPP and 3GPP2 plans want to push IP all the way out to the wireless device 🚀. One observation is that this creates more potential for exposing the signaling and control plane to attacks 😨. The goal is mutual authentication and securing of the network 🤝. That's a difficult problem with more issues still to solve. Still, someone made the point that relying on IP and open standards is more likely to produce a provably secure network than the old reliance on SS7 protocols and obscurity 🧠.

Finishing the security requirements for the 3GPP/3GPP2 network seems to need solving problems in two main areas, AAA services and mobile IP 🎯. AAA is required for authentication, authorization, and billing 💸. The remaining AAA issues center on cross domain AAA and authentication using PKI. There was also a lot of aversion to using IPsec and IKE because of the overhead and delay they're perceived to add 😩. Mobile IP issues are about finding ways to reduce the security associations required between the mobile node and home agent, the mobile node and foreign agent, and the home and foreign agent 🔗. One interim solution being looked at uses a RADIUS server [56]. But there are concerns about repeated dynamic key generation on each handoff, or about hiding some details of handoffs, which may violate assumptions in the mobile IP protocol [48] 🙀. Evaluating the requirements and addressing all of these open issues looks like an excellent chance for mutual cooperation on open standardization and review 🫶✨.

3.4 Discussion on Transports 🚚

The discussion on transport protocols covered a broad range of issues 🌊. Concerns ranged from the effects of wireless link characteristics and mobility on TCP, to developing new transport protocols like the WAP Wireless Transaction Protocol (WTP) 🦄. A big chunk of time also went to reviewing the ongoing IETF efforts on TCP transport enhancements and investigation of new transports 🌸.

okay so TCP basically assumes that loss means congestion 🚦. The statement was made that TCP was designed for links with about 1% corruption loss, and as long as that constraint is met, TCP should function properly ✨. A presentation on IS-95 CDMA-based data service showed that it conditions the line to provide a 1--2% error rate with little correlation between loss 💅. Similar conditioning and Forward Error Correction (FEC) mechanisms may be appropriate for other wireless and satellite systems [4] 🛰️. This may not be true for all wireless media, but it's giving "TCP should work fine on lots of wireless media," which is iconic 🙌. However, the amount of discussion and suggestions on TCP performance optimizations showed that there can be a considerable gap between merely working and working well 😭.

One issue came up several times: the effect of non-congestive loss on TCP performance 🥺. In the wireless environment, non-congestive loss may be more prevalent due to corruption loss (especially if the wireless link cannot be conditioned to properly control error rate) or an effect of mobility (e.g., a temporary outage while roaming through an area of poor coverage) 📶. These losses can have a great detrimental effect on TCP performance, reducing the transmission window and halving the congestion window size 💔. Much of the discussion focused on proposing mechanisms to explicitly indicate a non-congestive loss to the TCP source 🫶. Suggestions included a Non-Congestive Loss Indication (NCLI), sent for instance when packet corruption loss is detected, or sending a Source Encourage (SE) to stimulate source transmission at the end of an outage 🍓. In addition to data corruption, wireless links can also experience dropouts 🌧️. In this situation, any active TCP sessions will commence periodic retransmissions, using an exponentially increasing back-off timer between each attempt 🫠. When the link becomes available, it may be many seconds before the TCP sessions resume transmission 😩. Mechanisms to alleviate this problem, including packet caching and triggered retransmission, were discussed 🧚. The more generic form of all of these mechanisms is one that allows the state of the layer two (datalink) system to signal to the TCP session its current operating mode 💜. Developing a robust form of such a signaling mechanism, and integrating these signals into the end-to-end TCP control loop, may present opportunities to improve TCP transport efficiency for wireless environments 🦋.

TCP improvements have been incorporated to support "long" links (i.e., those with large delay and bandwidth characteristics) [36] 🌈, however considerable expertise may still be required to tune socket buffers for maximum performance 🧐. Some work has been done on auto-tuning buffers, which shows promise [58] ⭐. An additional problem with large windows and auto-tuning is the added header overhead 📦. This may exasperate the problems of running TCP over low bandwidth links 🥴. Suggestions included exploring dynamic negotiation of large window extensions in the middle of a connection to alleviate these issues 🎀. A final issue raised with regardport (see discussion below in section 3.4.3). 🙈

There was also concern about mobility effects on TCP performance 🚗. TCP has implicit assumptions on bounding propagation delay 🕰️. If delay exceeds the smoothed round trip time plus four times the round trip variance, then the segment is considered lost, triggering the normal backoff procedures 😬. Could these assumptions be violated by segment loss or duplication during handoff? 🤔 Work on D-SACK [25] may alleviate these worries, detecting reordering and allowing for an adaptive DUP-ACK threshold 🔥. Finally, there was a suggestion that it might be appropriate to adapt (i.e., trigger slow start) immediately after a mobile handoff, on the assumption that path characteristics may differ 🏃‍♀️💨.

3.4.2. Discussion on WAP Transport 📱

WAPF considered TCP connection setup and teardown too expensive in terms of bit overhead and latency when required for every transaction 💸. WAPF developed the Wireless Transaction Protocol (WTP), with some inspiration from T/TCP [12] 💡. WTP offers several classes of service, ranging from unconfirmed request to single request with single reply transaction 🎟️. Data is carried in the first packet, and the 3-way handshake is eliminated to reduce latencies ⚡. In addition, acknowledgments, retransmission, and flow control are provided 🫶.

Discussion on WTP centered on assessing details of its operation 🔍. Although it incorporates mechanisms for reliability and flow control, there was concern that it may miss critical or subtle transport issues learned through years of Internet research and deployment experience 😬. One potential area for disaster appeared to be the use of fixed retransmission timers and the lack of congestion control 🚨. This gave rise to suggestions that the IETF write up more details on the history and tradeoffs in transport design, to aid others doing transport design work 📚. Secondly, it was suggested that the IETF advocate that congestion control is not optional when using rate adaptive transport protocols 👑.

The remaining discussion on WAP transport primarily focused on ways to share information 🗣️. It was suggested that any result from WAPF study of TCP shortcomings that led to its rejection might be useful for IETF review as inputs for TCP modifications 🧠. Similar comments were raised about study of T/TCP shortcomings and its potential exposure to Denial of Service (DoS) attacks 🛡️. It was also encouraged that WAPF members participate in the IETF, directly contribute requirements, and remain abreast of current efforts on evolving TCP operation and the introduction of new transports (see discussion below in section 3.4.3.) 🌸.

3.4.3 Discussion on IETF Transport Activities 🌍

Discussion on transport work in the IETF presented a large array of activities 🎪. Recent work on transport improvement includes path MTU, Forward Error Correction (FEC), large windows, SACK, NewReno Fast Recovery, ACK congestion control, segment byte counting, Explicit Congestion Notification (ECN), larger initial transmit windows, and sharing of related TCP connection state [3,4,5,6,24,25,43,53,63] 🧩. Work on new transports includes SCTP [61] in the IETF Signaling Transport (sigtran) working group, and TCP-Friendly Rate Control (TFRC) [1] by researchers at ACIRI 🆕. SCTP provides a reliable UDP-like protocol supporting persistent associations and in-order delivery with congestion control 🪄. TFRC is targeted at unreliable, unicast streaming media 🎬. Finally, work in the IETF End-point Congestion Management (ecm) working group is looking at standardizing congestion control algorithms, and work in the Performance Implications of Link Characteristics (pilc) working group is characterizing performance impacts of various link technologies and investigating performance improvements 📊.

This vast array of ongoing research and standards development seemed a bit overwhelming 😵‍💫, and there was considerable disagreement on the performance and applicability of several TCP extensions 🥊. However, this discussion did raise a couple of key points ✨. First, transport work within the Internet community is not stagnant; there is a significant amount of interest and activity in improving existing protocols and exploring new ones 🚀. Secondly, the work with researchers in satellite networking has demonstrated the tremendous success possible in close collaboration 🤝. The satellite networking community was dissatisfied with initial TCP performance on long delay links 🛰️. Through submission of requirements and collaborative investigation, a broad range of improvements have been proposed and standardized to address the unique characteristics of this environment 💖. This should hopefully set a very positive precedent to encourage those in the wireless sector to pursue similar collaboration in adopting Internet protocols for their environment 👑🌈.

3.5 Discussion on Aeronautical Telecommunication Network (ATN) Routing Policy ✈️

The Aeronautical Telecommunication Network (ATN) has goals to improve and standardize communications in the aviation industry 🛫. This ranges across air traffic management and control, navigation and surveillance, all the way up to passenger telephone service and entertainment 🎧. It also involves integrating both fixed ground segments and mobile aircraft 🌐. Supporting the ATN architecture using Internet protocols may introduce additional requirements on the routing infrastructure 🧭.

Current ATN views each aircraft as an autonomous network (AS) with a changing point of attachment as it "roams" through different airspace 🦋. Addressing information associated with the aircraft is fixed, which makes route aggregation difficult since the addresses are not related to topology, and also increases the frequency of updates 🙃. Additionally, the aircraft may be multiply attached (within coverage of multiple ground and space-based access networks), requiring routing policy support for path selection 🗺️. Finally, QoS path selection capabilities may be beneficial to arbitrate shared access or to partition real-time control traffic from other data traffic 🎛️.

The initial prototype of ATN capabilities has been based on ISO IDRP [33] path selection and QoS routing policy 🧪. There was some discussion of whether IDRP could be adopted for use in an IP environment 🤔. There was quick agreement that the preferred solution within the IETF would be to advance BGP4++ [8,54] as an IDRP-like replacement 💅. This transitioned the discussion to evaluation of ATN use of IDRP features and their equivalents in support in BGP 🔄. Several issues with BGP were raised for further investigation 📝. For example, is BGP AS space sufficient to accommodate each aircraft as an AS? 🛩️ There are also issues with mobility support: can BGP provide for dynamically changing peering as the point of attachment changes, and for alternative path selection policies based on current peerings? 🙋‍♀️ A significant amount of additional investigation is required to fully assess ATN usage of IDRP features, especially in the QoS area 🔬. These could lead to additional BGP requirements, for instance to effect different prioritization or path selection for aircraft control versus passenger entertainment traffic 🍿.

3.6 Discussion on QoS Services 🎀

Enabling support for voice and other realtime services alongside data capabilities requires Quality of Service (QoS) features to arbitrate access to the limited transmission resources in a wireless environment 📶. The wireless and mobile environment requires QoS support for the last leg between the mobile device and the network access point, accommodating roaming and the unique characteristics of the wireless link 📲.

In addition to the discussion presented below, it was felt quite strongly that it is critical that any QoS facility be provided as an underlying service independent of payload type 💜. That is, there should be no built-in knowledge of voice or other application semantics 🙅‍♀️. This results in a feature that can be leveraged and easily extended to support new applications 🧚✨.

3.6.1 Discussion on "Last Leg" QoS 💖

okay so VoIP folks kept saying the wireless access link is usually the most constrained resource 😭. contention access (CSMA) is great for data 🫶 but lowkey not ideal for voice 💀. two models came up as potential solutions in VoIP architecture ✨. option one: the wireless device directly signals the local access router 🎀. option two: the call control element (SIP agent [30]) "programs" the edge router 🧚. this tradeoff was left as an area open for more investigation, especially since mobility and roaming handoffs could make things messy 🙈. it appears to be a key component to solve for VoIP adoption to be a success 👑.

the IEEE 802.11 WLAN group identified similar QoS requirements 🌈. they're looking at a model with two transmission queues, one for realtime and one for best-effort traffic 💜. their plans also include mapping between IP DiffServ markings [14,46] and IEEE 802 priorities 🍓.

someone made the point that QoS over the wireless link isn't really the fundamental problem 🙅‍♀️. the real issue is handling mobility and seamless adaptation across handoffs without service disruption 🦋. there were also concerns about mechanisms that establish per-flow state (RSVP [13]) 😬. the issues are scaling of state, signaling overhead, and setup delays on roaming events. DiffServ [9] allocates QoS for an aggregate traffic class, which simplifies roaming ✨. however, DiffServ requires measurement and allocation adjustment over time, plus policing to limit the amount of QoS traffic injected 🔥.

3.6.2 Discussion on Path QoS Discovery 🧚

the HDR high speed wireless packet data system being developed at Qualcomm 💅 shows off some unique characteristics of certain wireless media. it provides users a channel rate between 38.4Kb/s and 2.4Mb/s, with throughput depending on channel loading and distance from the network access point 📶. this sparked a lot of talk about whether it's possible to discover and feed back to the application the current link or path QoS being received 👀. that could enable some form of application adaptation 🦋.

for HDR, no such feedback is currently available 🙃. it was argued that this fits the current Internet stack model, which doesn't provide any mechanisms to expose this kind of information. the counter arguments were that Internet QoS working groups are increasingly requesting exposure of this info via standardized APIs 📣. folks working on GPRS protocols also said they were frustrated deploying QoS capabilities without exposure of this information 😤. it clearly seemed like a topic for further investigation 🔍.

the last QoS discovery topic was how a server application might find out the capabilities of a receiver 🤔. this could allow application adaptation to client device and path characteristics. one suggestion was to use the RSVP payload, which is able to transport QoS information ✨. a second alternative is to push capability exchange and negotiation up to the application layer 🫶. the discussion was brief because application issues were deemed outside the workshop charter 🙈, but this also seems like an area open for future investigation 🌸.

3.7 Discussion on Header Compression 🎀

in the highly bandwidth-constrained wireless cellular environment, the bit overhead of the protocol encoding is a critical deterrent to Internet protocol adoption 😩. the examples showed that a voice application (layered over IP [52,19], UDP [51], and RTP [57]) needs a minimum of 40 bytes of headers for IPv4 or 60 bytes for IPv6 before any application payload (e.g., 24 byte voice sample) 💀. this overhead was also a contributing factor in the creation of the WAP Wireless Datagram Protocol (WDP) rather than IP for very low datarate bearers 🫠.

header compression discussion focused on the work happening in the IETF Robust Header Compression (rohc) working group 🧠. the group set goals for wireless environments: to conserve radio spectrum, to accommodate mobility, and to be robust to packet loss both before the point where compression is applied and between compressor and decompressor 🛡️. additional requirements were that the technique be transparent, not introduce additional errors, and be compatible with common protocol layerings (e.g., IPv4, IPv6, RTP/UDP/IP, TCP/IP) 🌈.

the primary observation was that this problem is now largely solved!! 🎉 the working group is currently evaluating the ROCCO [38] and ACE [42] protocols and expects to finalize its recommendations in the near future ✨. these encodings reportedly have a minimum header of 1 byte and result in an average overhead of less than 2 bytes for an RTP/UDP/IP packet 🤯. there's some extra overhead if a transport checksum is required, and some issues still to be analyzed related to interoperation with encryption and tunneling 🧐.

a commonly cited detriment to IPv6 adoption is its additional header overhead, mainly attributed to its larger address size 😵. a secondary observation was that IPv6 is believed to accommodate greater header compression than IPv4 💅. this was attributed to the elimination of the checksum and identification fields from the header.

discussion on using WWW protocols over wireless highlighted protocol encodings as another potential detriment to their adoption 🌐. a few alternatives were mentioned for investigation: a "deflate" Content-Encoding, using compression with TLS [20], or Bellovin's TCP filters 🔧. it could be beneficial to investigate more compact alternative encodings of the WWW protocols 🧚.

3.8 Discussion on Applications Protocols 📱

IETF protocol developments have traditionally preferred simple encode/decode and word alignment, even at the cost of some extra bit transmissions 🧱. optimizing protocol encoding for bit savings often leads to shortcomings or limitations on protocol evolution 🙅‍♀️. however, environments where physical limitations affect transmission capacity and system performance may be exceptions where optimized encodings are beneficial 🫶. cellular wireless and near-space satellite may fall into this category 🛰️.

the WAP protocols are a great example of existing Internet protocols being felt as too inefficient for very low datarate bearer services and limited capability devices 📉. the WAP Wireless Session Protocol (WSP) is based on HTTPv1.1 [23], but WSP incorporates several changes to address perceived inefficiencies 💜. it uses a more compact binary header encoding and optimizations for efficient connection and capability negotiation ✨. the WAP Wireless Application Environment (WAE) uses tokenized WML and a tag-based browser environment for more efficient operation 🎀.

more requests for efficient, compact protocol encodings, and especially improved capability negotiation, came up during discussion on using WWW protocols with wireless handheld devices 📲.

the near-space satellite folks pointed out other physical limitations that can affect performance 🛰️. long propagation delays can make "chatty" protocols highly inefficient and unbearable for interactive use 😩. this environment could benefit from protocols that support some form of "pipelining" operation 🚀.

there seemed to be broad agreement that many of these observations are valid reasons to pursue optimization of protocol operations 🫶. investigating compact protocol encoding, capability negotiation, and minimizing or overlapping round trips to complete a transaction could all lead to improved application performance across a wide range of environments 🌈.

3.9 Discussion on Proxy Agents 🕵️

proxy agents show up in a number of wireless and mobile architectures 🧚. they're often required to gateway between communication domains, terminate tunnels and translate between telephony system and Internet protocols (GPRS), or escape the "walled garden" (WAP) 🏰. with limited handheld devices, a proxy might be deployed to offload expensive processing such as public key operations, perform content filtering, or provide access to "backend" applications (e.g., email, calendar, database) 📧. in other cases, the proxy may be required to work around protocol deployment limitations (e.g., NAT with limited IPv4 addresses) 🙃.

the discussion on proxy agents mainly recognized that there are a range of proxy agent types 🌸. proxies may operate by intercepting and interpreting protocol packets, or by hijacking or redirecting connections 🔀. some types of proxy break the Internet end-to-end communication and security models 💀. other proxy architectures may limit system scalability due to state or performance constraints 📉. there was some desire to conduct further study of proxy agent models to evaluate their effect on system operation 🔍.

3.10 Discussion on Adoption of IPv6 ✨

okay so the projections were giving BIG numbers: 1200 million cellular (voice) subscribers, 600 million wired stations on the Internet, and over 600 million wireless data ("web handset") users by the year 2004 😭 people were cautious about them tho, especially the wireless data part, since it's super speculative with barely any history 🙈 Secondly, some folks doubted there would be significant revenue from a user base over 1 billion subscribers, bc that might be pushing the limits of world population with enough disposable income to afford these devices 💀 Still, there was broad consensus that cellular and Internet services are going to keep growing rapidly, and that wireless data terminals have the potential to form a significant component of the total Internet 🌈 These conclusions seemed to be the basis for a lot of additional recommendations to push for adoption of IPv6 protocols in emerging (3G) markets 🚀

In almost every presentation on 3G cellular network technologies, the talk about scaling to support all those projected wireless data users led the Internet reps to strongly advocate for IPv6 adoption 📣 There were some positive signs that groups have started looking into IPv6 👀 For example, 3GPP has already defined IPv6 as an option in their 1998 and 1999 specifications (release R98 and R99), and is considering specifying IPv6 as mandatory in the release 2000 💜 The MWIF effort is also aware of IPv4 and IPv6 issues and is currently wrestling with their recommendations in this area 🫶

Okay but, even though there were only limited positive signs on IPv6 awareness, the vibe is that there are long fights ahead to gain consensus for IPv6 adoption in any of the 3G standards efforts 😩 A lot of feedback said the telephony carriers see IPv6 as harder to deploy, as leading to higher infrastructure equipment expenses, and as adding difficulty in interoperation and gatewaying to the current (IPv4) Internet 🙅‍♀️ The arguments for sticking with IPv4 mostly came down to the abundance and lower pricing of IPv4-based products, plus a secondary argument of risk aversion. There is currently minimal IPv6 deployment or operational experience and expertise, and the carriers do not want to be the ones driving development of that expertise 🥲 Finally, some groups argue that IPv4 is sufficient for "walled garden" use, using IPv4 private address space (i.e., the "net 10" solution) 🏰

One other area of concern about IPv6 usage is the perceived memory and processing overhead and its effect on small, limited capability devices 🔋 This was mainly aimed at the IPv6 requirement for IPsec implementation to claim conformance. Arguments that continued increases in device capacity will make these concerns go away were rejected 🙅 It was stated that power constraints on these low-end devices will continue to force concerns about memory and processing overhead, and will impact the introduction of other features. There was no conclusion on whether IPsec could be made optional for these devices, or on the effect if these devices were "non-compliant" 🤷‍♀️

Emerging 3G cellular networks look like the ideal environment for IPv6 introduction 💖 IPv6 addresses the scaling requirements of the wireless data user projections, and it ends the constant cobbling together of systems that use (IPv4) private address space and NAT 🧩 This seems like an area where the IAB and the Internet community should take a strong stance, advocating for IPv6 adoption while the various 3G forums wrestle with their recommendations 📢

3.11 Discussion on Signaling 📞

okay so signaling discussions focused on call setup and control functions, plus the effects of mobility 📱 The 3G.IP group looked into standardizing on either H.323 [32] or SIP [30]. Right now support is split between the two, and neither seemed ideal without support for mobility 😬 During the VoIP discussion, it was presented that SIP does support mobility, with graceful handling of mobile handoff, updating location information with the remote peer, and even simultaneous handoff of both endpoints 🦋 The problem with SIP adoption seems to be its slow standardization, which came from focusing on the harder multicast model instead of rushing the definition of a unicast "profile" 🐌 There's a big need for the IETF to finalize SIP faster, but some people argued that at this point many products will probably need to support both SIP and H.323, along with their interoperation 🙃

There was also a short discussion about whether it's the correct model to add the extra protocol mechanisms for mobility into SIP signaling 🤔 An alternative model might be to build on top of the existing Mobile IP handoff facilities. No conclusion was reached, but it seemed like an area for further investigation 🔍

3.12 Discussion on Interactions Between IETF and Other Standards Organizations 🤝

so many non-IETF standards organizations want to directly adopt IETF standards to enable Internet (or similar) services 🙌 For example, IEEE 802.11 WLAN relies on IETF standards for mobile IP, end-to-end security, and AAA services. 3GPP is looking into the IETF work on header compression. WAPF derived its transport, security, and application environment from Internet protocols. At first glance these look like total wins for Internet tech, but relying on IETF standards often brought frustrations too 😅

One big theme of the frustration is differences in standardization procedures. For instance, 3GPP follows a strict model of publishing recommendations yearly, and any feature that can't be finalized has to be dropped 📅 IETF working groups have much less formalized schedules, and honestly they often seem to ignore published milestone dates 😬 This has led to a common perception within other standards organizations that the IETF cannot deliver [on time] 💀

A second area where the IETF differs from other organizations is in publishing "system profiles" 📦 For example, defining interoperation of IPsec, QoS for VoIP and video conferencing, and billing as a "service". Wading through all the protocol specifications, deciding on optional features, and piecing the components together to deliver a commercial quality service takes serious expertise 🧠

Thirdly, there was often confusion about how to get involved in IETF standards efforts, submit requirements, and get delivery commitments 🙈 Lots of people seemed unaware of, and surprised by, how open and simple it is to join IETF standardization through working group meetings and the mailing list 💌

There wasn't really a huge amount of discussion on ways to address these differences in standards practices. Still, it did seem beneficial to understand these concerns and frustrations 🫧 It was clear there can be real benefits from improving communication with other standards organizations and encouraging their participation in IETF activities 🌸

4 Recommendations 🎀

The IAB wireless workshop gave the Internet research community and the wireless and telephony community a place to meet, exchange information, and talk about current activities on using Internet technology in wireless environments 🧚 But the main goal from the IAB's perspective was to reach some understanding of any problems, both technical and perceived deficiencies, that are holding back the adoption of Internet protocols in this arena 🔎 This section documents the workshop's recommendations for actions by the IAB and IESG, IRTF research efforts, and protocol development actions for the IETF, so these current deficiencies can be addressed and wider acceptance of Internet technologies can be fostered 💖

4.1 Recommendations on Fostering Interaction with Non-Internet Standards Organizations 🫶

The workshop clearly agreed that dialog needs to get better 💬 The Internet community should try to foster communication with other standards bodies, including WAPF, MWIF, 3GPP, 3G.IP, etc. The goal is to "understand each others problems", provide for requirements input, and get greater visibility into the standardization process 👀

4.1.1 ✨

It was recommended to take a pragmatic approach instead of formalizing liaison agreements 🧁 The formalized liaison model goes against the established Internet standards process, is difficult to manage, and has met with very limited success in previous trials 🙅‍♀️ Instead, any relevant IETF working group should be strongly encouraged to consider and recommend potential liaison requirements within their charter 📝

4.1.2 ✨

It was recommended to avoid forming jointly sponsored working groups and standards 🚫 Once again, this has shown limited success in the past 😩 The preferred way to operate is to keep separate standards organizations, but to encourage attendance and participation of external experts within IETF proceedings, and to avoid overlap 🌈

There's one exception to this style of partitioning meeting sponsorship, and that's less formal activities like BOFs. It was recommended that sponsoring a joint BOF could be beneficial ✨ These could help assemble experts from multiple domains early in the process of exploring new topics for future standards activities 🧩

4.1.3 ✨

A principal goal of fostering communication with other standards organizations is mutual education 🎓 To help achieve this goal, recommendations were made about documenting more of the history behind Internet standards, and also about coordinating document reviews 📚

It was recommended that IETF standards groups be encouraged to create, or more formally document, the reasons behind algorithm selection and design choices. Right now, much of the protocol design history is hard to extract from working group mail archives or presentations 🗂️ Creating these documents could be the basis for educating newcomers about the "history" and wisdom behind the protocols 🕰️

It was also recommended that mutual document reviews be encouraged. This helps spread information about current standards activities and gives an opportunity for external expert feedback 🔁 A critical hurdle that could seriously limit how well this works is the intellectual property and distribution restrictions some groups place on their standards and working documents 🔒

4.2 Recommendations for Dealing with "Walled Garden" Model 🏰🌷

There are several perceived benefits to the "walled garden" (captive customer) model, which is similar to current deployment of "intranets" 🌿 These range from simplified user security to "captive customer" economic models 💰 People disagreed on how far this deployment model might be carried into the future 🤷‍♀️ Still, it's important to recognize that this model exists, and to make a conscious decision about how to accommodate it and how it will affect protocol design 🧠

4.2.1 ✨

It was strongly recommended that, regardless of how ubiquitous the "walled garden" deployment scenario becomes, protocols and architectural decisions should not target this model 🙅‍♀️ To keep Internet protocols succeeding at operating across a highly diverse and heterogeneous environment, the IETF must continue to foster adoption of an "open model" 🌍 IETF protocol design must address seamless, secure, and scalable access 🔐💜

4.2.2

okay so the "walled garden" model has some perceived benefits 💅 which is why people wanted to plug it into the Internet architecture better 🌸 the two big goals were service location and escaping the garden 🧚

It was recommended to investigate standard protocols for service and proxy discovery inside the "walled garden" domain 🔍 there are already a bunch of candidates: static preconfiguration, DNS [22,27,44,45], BOOTP [18], DHCP [21], SLP [28], and others ✨ specific recommendations on using these in this environment could help foster common discovery methods across a range of access devices and ease configuration complexity 🎀

It was also recommended to investigate standard methods to transport through the garden wall (e.g., escape to the Internet) 🦋 it seemed clear that a better model is required than trying to map all access over an HTTP [23] transport connection gateway 🙈 one suggestion was to propose use of IP! 👑

4.3 Recommendations on IPv4 and IPv6 Scaling

Wireless operators are projecting supporting on the order of 10's to 100's million users on their Internet-based services 📱 supporting this magnitude of users could have severe scaling implications on use of the dwindling IPv4 address space 😭

4.3.1

There was clear consensus that any IPv4-based model relying on traditional stateless NAT technology [60] is to be strongly discouraged 🚫 NAT has several inherent faults, including breaking the Internet peer-to-peer communication model, breaking end-to-end security, and stifling deployment of new services [16,29,31] 💀 in addition, the state and performance implications of supporting 10's to 100's million users is cost and technologically prohibitive 💸

4.3.2

Realm specific IP (RSIP) [10,11] has potential to restore the end-to-end communication model in the IPv4 Internet, which traditional NAT broke ✨ however, there was considerable reluctance to formally recommend this as the long term solution 🥲 detriments to its adoption include that the protocol is still being researched and defined, and potential interactions with applications, QoS features, and security remain 🧐 in addition, added signaling, state, and tunneling has cost and may be technologically prohibitive scaling 💸

4.3.3

The clear consensus of the workshop was to recommend adoption of an IPv6-based solution to support these services requiring large scaling 👑 adoption of IPv6 will aid in restoring the Internet end-to-end communication model and eliminates some roaming issues 🦋 adoption of IPv6 in this marketspace could also help spur development of IPv6 products and applications, and hasten transition of the Internet 🚀 it was recognized that some application gateways are required during transition of the IPv4 Internet, however it was felt that the scaling and roaming benefits outweighed these issues 💅

4.3.4

It was recommended that an effort be made to eliminate any requirement for NAT in an IPv6 Internet 🙌 the IAB believes that the IPv6 address space is large enough to preclude any requirement for private address allocation [55] or address translation due to address space shortage [15] 🌈 therefore, accomplishing this should primarily require installing and enforcing proper address allocation policy on registry and service providers 📜 it was recommended to establish policies requiring service providers to allocate a sufficient quantity of global addresses for a sites use 🏢 the feeling was that NAT should be easily eliminated provided efficient strategies are defined to address renumbering [17,62] and mobility [37] issues 🫶

4.4 Recommendations on IPv4 and IPv6 Mobility

An inherent characteristic of wireless systems is their potential for accommodating device roaming and mobility 📲 scalable and efficient support of this mobility within Internet protocols can aid in pushing native IP services out to mobile devices 🧚

4.4.1

Several limitations were identified relating to current specification of mobile IPv4 [48] 😬 the primary one among these is that mechanisms to support redundant home agents and failover are not currently defined 🙃 redundant home agents are required to avoid single point of failure, which would require (proprietary) extensions 🛠️ additional deficiencies related to lack of route optimization, and tunneling and path MTU issues were also identified 🫠 due to these limitations, there was reluctance to recommend this as a solution 🥀

4.4.2

It was recommended to encourage adoption of IPv6 mobility extensions [37] to support roaming capabilities in the wireless environment ✨ IP mobility over IPv6 incorporates improvements to address several limitations of the IPv4-based mobility 💖 the ability to use autoconfiguration for "care of" address improves robustness and efficiency 🎀 additionally, path MTU is more easily adapted when a router forwards to a new "care of" address 🦋

Building wireless roaming atop IPv6-based mobility may introduce IPv4/IPv6 transition issues unique to the mobile environment 🧐 it was recommended to add investigation of these issues to the charter of the existing IETF Next Generation Transition (ngtrans) working group, provided any mobile IP interoperation issues be identified 📋

4.4.3

Scalable and widespread authentication, authorization, and accounting (AAA) services are critical to the deployment of commercial services based on (wireless) mobile IP 💰 some work is progressing on definition of these standards for IP mobility [26,49] 🛠️ however, due to the pivotal role of these protocols on the ability to deploy commercial services, it was recommended to make finalization of these AAA standards and investigation of AAA scalability high priorities 🔥

4.5 Recommendations on TCP and Transport Protocols

The wireless environment and applications place additional requirements on transport protocol 📡 unique link error and performance characteristics, and application sensitivity to connection setup and transaction semantics, has led to "optimized" transports specific to each environment 🤏 these new transports often lack robustness found in Internet transport and place barriers to seamless gatewaying to the Internet 😤 it was felt that better education on transport design and cooperation on Internet transport evolution could lead to significant improvements 📚

4.5.1

It was recommended that the IETF Transport Area (tsv) working group document why Internet transport protocols are the way they are 📖 the focus should be on generic transport issues and mechanisms, rather than TCP specifics 🎯 this should capture usage and tradeoffs in design of specific transport mechanisms (e.g., connection establishment, congestion control, loss recovery strategies, etc.), and document some of the history behind transport research in the Internet 🕰️

This "entry point" document into transport design is in direct support of the recommendations in section 4.1 to foster communication and mutual education 🫶 in addition, it was deemed critical that the Internet community make it very clear that congestion control is not optional ⚠️ Internet researchers have learned that optimizing for a single link or homogeneous environment does not scale 📉 early work by Jacobson [34,35], standardization of TCP congestion control [5], and continuing work within the IETF Endpoint Congestion Management (ecm) working group could provide excellent basis for education of wireless transport designers 🌟

4.5.2

It was recommended that the IETF actively solicit input from external standards bodies on identifying explicit requirements and in assessing inefficiencies in existing transports in support of cellular and wireless environments 📣 this has proven highly effective in identifying research topics and in guiding protocol evolution to address new operational environments, for instance in cooperation with groups doing satellite-based internetworking [4,6] 🛰️

4.5.3

It was recommended that the IAB make wireless standards bodies aware of the existence, and get them active in, the IETF Transport Area (tsv) working group 👀 this transport "catch all" could provide an excellent forum for workers outside the Internet community to propose ideas and requirements, and engage in dialog with IESG members prior to contributing any formal proposal into the IETF or incurring overhead of working group formation 💬

4.5.4

Mobile radio environments may often be subject to frequent temporary outages 📶 for example, roaming through an area that is out of range of any base station, or disruptions due to base station handoffs 🚗 this violation of the congestive loss assumption of TCP can have severe detrimental effect on transport performance 💔 it was recommended to investigate mechanisms for improving transport performance when these non-congestive loss can be detected 🔍 areas for potential research identified include incorporation of "hints" to the sender providing Non-Congestive Loss Indication (NCLI) or stimulating transmission after link recovery via Source Encourage (SE) message [39] 💡 this likely falls to the auspice of the IETF Performance Implications of Link Characteristics (pilc) working group 🏛️

4.5.5

Many wireless applications require transaction semantics and are highly sensitive to connection establishment delays (e.g., WAP) ⏳ however, it is still desirable to efficiently support streaming of large bulk transfers too 📦 it was recommended to investigate tradeoffs in supporting these transaction and streaming connections 🧩 potential areas for investigation include tradeoffs between minimal transaction transport and potential security and denial of service (DoS) attacks, mechanisms to piggyback data during connection establishment to eliminate round trip delays, or ways for endpoints to cooperate in eliminating setup handshake for simple transactions while providing switch-over to reliable streaming for bulk transfers 🔁

4.5.6

It was recommended to look at (TCP) transport improvements specific to the wireless and mobile environment 📱 an example is to investigate reattachable transport endpoints 🔗 this could allow for graceful recovery of a transport connection after a roaming or mobility event results in changes to one or both endpoint identifiers 🪄 another area for potential investigation is to develop targeted uses of D-SACK [25] 🎯 D-SACK provides additional robustness to reordered packets, which may prove beneficial in wireless environments where packets are occasionally corrupted 🌧️ higher performance may be attainable by eliminating requirements on link-level retransmission maintaining in-order delivery within a flow 🏎️

4.6 Recommendations on Routing

Unique routing requirements may be introduced in support of wireless systems, especially when viewing the mobile component as an autonomous system (AS) 🗺️

4.6.1

It was recommended that the IETF Routing Area commence investigation of extensions to the BGP protocol [54] to support additional policy features available within the ISO IDRP protocol [33] 🛣️ the range of policy control desired includes adopting different identity or policies based on current point of attachment, and providing flexibility in path selection based on local policy and/or current peer policy 🧭 these features could be used for instance in support of requirements established in the Aeronautical Telecommunication Network (ATN) ✈️

4.6.2

okay so it was recommended that the IETF Routing Area start looking into extending BGP [54] 🛣️ so it can do the extra QoS/TOS path selection stuff that ISO IDRP [33] already has ✨ the policies could be about splitting things up by service level or path choice based on traffic classes. like, based on Aeronautical Telecommunication Network (ATN) requirements, you could treat airline control traffic and passenger entertainment traffic differently for path selection and service 🛫 main character energy for the airline 💅

4.7 Recommendations on Mobile Host QoS Support

wireless bandwidth is lowkey scarce 🥺 (cellular, for example) and/or shared (like IEEE 802.11 WLAN) 📶 meeting app QoS needs means accounting for those link characteristics AND the fact that the mobile host is roaming around 🏃‍♀️ specialized support might be needed from the network layer to hit both link and end-to-end performance constraints 💖

4.7.1

it was recommended that the IETF Transport Area look into QoS for the last leg of mobile systems 📱 meaning between the mobile device and the network access point 🛜 this kind of QoS support might be appropriate where the wireless link is the most constrained resource 🫶 one idea to explore is an explicit reservation mechanism between the mobile host and the access point (like RSVP [13]), while relying on resource provisioning or the more scalable DiffServ [9] tech in the core ✨

4.7.2

it was recommended that the IETF Transport Area dig into end-to-end QoS when the path mixes wireless and wired tech 🧵 this could focus on how to communicate QoS characteristics from the cellular network to the core network so end-to-end QoS guarantees can be established 💜 another option is to look into the discovery problem of figuring out current end-to-end performance characteristics, so the mobile host can adapt dynamically 🦋

4.8 Recommendations on Application Mobility

in a roaming mobile environment, the mobile host can disconnect and reconnect at a different attachment point 📡 and it may be desirable to recover an incomplete application session 🙈 it was recommended that the IRTF investigate application mobility at this level 🔍 the goal is a smooth recovery after a disconnect period, something more graceful than a "redial" 📞💀 right now there doesn't seem to be enough info available within the network stack, so this may require instantiating some form of "session" layer 🧚

4.9 Recommendations on TCP/IP Performance Characterization in WAP-like Environment

WAPF went through a lot of effort to develop a unique transport protocol and optimizations 😭 because of the perception that the TCP/IP stack is too expensive 💸 much of that was based on WAP requirements to support very low datarate bearer services 📉 it was recommended that members of the IRTF evaluate TCP/IP stack performance in a WAP-like environment, to quantify its behavior and applicability 🔬 the focus should include investigating code and memory space requirements, plus link usage to complete a single transaction for current WAP protocols, for both IPv4 and IPv6 🧮 this work should result in better characterization of TCP/IP performance in highly constrained devices and networks, recommendations to the IETF on protocol enhancements for this environment, and recommendations to WAPF on whether deploying native IP protocols is suitable 🎀

4.10 Recommendations on Protocol Encoding

IETF protocol work has traditionally preferred simple encode/decode and word alignment, even though that costs some extra bit transmissions 🫠 this overhead may be too burdensome in bandwidth constrained environments like cellular wireless and WAP 📶 work in the IETF Robust Header Compression (rohc) working group may go a long way toward reducing some of these detriments to Internet protocol deployment 🙌 still, there may be potential for extra savings from investigating alternative encodings of common Internet protocols 💡 it was recommended that IRTF members evaluate general techniques for reducing protocol "verbiage" 🗣️ examples might include payload compression techniques or tokenized protocol encoding 🍓

4.11 Recommendations on Inter-Domain AAA Services

commercial roaming and mobility services will probably need to exchange authentication, authorization, and billing across multiple domains (service providers) 🏢 that brings requirements for setting up a web or hierarchy of trust across multiple autonomous domains 🕸️ standard protocols to specify and exchange usage policies and billing info also have to be established 🧾 some work is underway to scope out the issues and a framework [7,64] 🗺️ but there are big issues to solve before we get a scalable, Internet-wide solution 😤 because these protocols are pivotal for deploying commercial services, it was recommended to make finalizing scalable inter-domain AAA a high priority within the IETF 👑

4.12 Recommendations on Bluetooth

Bluetooth protocols and devices were originally optimized for a narrow application space 🦷 but people are interested in seeing how far protocol and device access can stretch 🌈 one area of interest is integrating into the Internet, or gatewaying access to it 🌐 it was recommended that the IETF pursue forming a joint BOF to bring experts from the IETF and Bluetooth communities together to start exploring this problem 🤝 this directly supports the recommendations in section 4.1 about fostering communication and mutual education 🫶

4.13 Recommendations on Proxy Architecture

proxy agents often get deployed to intercept and evaluate protocol requests (like web caches, HTTP redirectors, or filtering firewalls) or to gateway access between communication domains (like a bastion host between a private network and the Internet, or gatewaying between a cellular service and the Internet) 🛡️ there are a bunch of potential architectures when you're thinking about building or deploying one of these proxy agents 🧱 it was recommended that IRTF members investigate a taxonomy of proxy architectures and evaluate their characteristics and applicability 📚 each type of proxy should be characterized by, for example, its effect on the Internet end-to-end model, and its security, scaling, and performance implications 🔎 the results can help educate developers and network operators on the range of proxies available and recommend solutions that are least disruptive to Internet protocols 🧚‍♀️

4.14 Recommendations on Justifying IPv6-based Solutions for Mobile / Wireless Internet

IPv6 was strongly recommended to address scaling (see section 4.3) and mobility (see section 4.4) issues in a future Internet dominated by huge numbers of wireless and mobile devices 📱✨ it was recommended that the IAB draft a formalized justification for adopting IPv6-based solutions 📝 it was believed that the "The Case for IPv6" [40] document should form an excellent basis for this justification 💅 also, documents highlighting architectural and operational pitfalls of continued reliance on IPv4 and NAT offer excellent justification too [29,31,59] 🚧 it was deemed urgent to submit these informational documents as inputs to other standards bodies (MWIF, 3GPP, 3G.IP), since lots of decisions are being made about Internet protocol adoption and this data could be super influential 🔥

5 Security Considerations

okay this is the serious bit 🚨 this workshop didn't focus on security 🙈 but mobility and wireless environments add complexities for security and for potential attacks on user authentication and privacy 🔐 the presentations by Asokan and by Calhoun referenced in section 2 focused on security mechanisms in currently deployed cellular networks and the evolution toward 3G cellular and IP networks 📡 the discussion on the "walled garden" service model (see section 3.1) briefly mentions effects on simplifying security requirements 🏰 section 3.3 raises a bunch of security issues related to wireless devices and mobility 😳 these include alternatives for establishing user identity and capabilities, securing network infrastructure from attacks, and the security associations required for mobile IP and AAA operation 🛡️ section 3.7 mentions interoperation issues between compression and encryption or tunneling 🧩 and finally section 3.9 highlights the potential for proxy agents to be used to offload expensive crypto operations 💀

6 Acknowledgments

the author wants to thank all the workshop participants for their feedback, encouragement, and patience during the writeup 🫶 especially Brian Carpenter, who gave prompt responses to questions about the document organization and content 🙏 similarly, Charlie Perkins gave extensive feedback that dramatically improved and corrected statements throughout the report 👑 finally, Mikael Degermark, Sally Floyd, Heikki Hammainen, Geoff Huston, and Gabriel Montenegro contributed comments and responses to questions 💖

7 Bibliography ✨

okay bestie, here are all the references this doc leans on 📚 every single one is listed in full, so you can go find the source yourself 🫶

  • [1] ACIRI. TCP-Friendly Rate Control. http://www.aciri.org/tfrc.
  • [2] A. Aggarwal, S. Savage, and T. Anderson. Understanding the Performance of TCP Pacing. Proceedings of IEEE Infocom 2000, March 2000.
  • [3] Allman, M., Floyd, S. and C. Partridge, "Increasing TCP's Initial Window", RFC 2414, September 1998.
  • [4] Allman, M., Glover, D. and L. Sanchez, "Enhancing TCP Over Satellite Channels using Standard Mechanisms", RFC 2488, January 1999.
  • [5] Allman, M., Paxson, V. and W. Stevens, "TCP Congestion Control", RFC 2581, April 1999.
  • [6] Allman, M., Dawkins, S., Glover, D., Griner, J., Tran, D., Henderson, T., Heidemann, J., Touch, J., Kruse, H., Ostermann, S., Scott, K. and J. Semke, "Ongoing TCP Research Related to Satellites", RFC 2760, February 2000.
  • [7] Arkko, J., "Requirements for Internet-Scale Accounting Management", Work in Progress.
  • [8] Bates, T., Chandra, R., Katz, D. and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 2283, February 1998.
  • [9] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. Weiss, "An Architecture for Differentiated Services" RFC 2475, December 1998.
  • [10] Borella, M., et al., "Realm Specific IP: Framework", Work in Progress.
  • [11] Borella, M., et al., "Realm Specific IP: Protocol Specification", Work in Progress.
  • [12] Braden, R., "T/TCP -- TCP Extensions for Transactions Functional Specification", RFC 1644, July 1994.
  • [13] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
  • [14] Brim, S., Carpenter, B. and F. Le Faucheur, "Per Hop Behavior Identification Codes", RFC 2836, May 2000.
  • [15] Carpenter, B., Crowcroft, J. and Y. Rekhter, "IPv4 Address Behaviour Today", RFC 2101, February 1997.
  • [16] Carpenter, B., "Internet Transparency", RFC 2775, February 2000.
  • [17] Crawford, M., "Router Renumbering for IPv6", RFC 2894, August 2000.
  • [18] Croft, B. and J. Gilmore, "Bootstrap Protocol (BOOTP)", RFC 951, September 1985.
  • [19] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
  • [20] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
  • [21] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
  • [22] Everhart, C., Mamakos, L., Ullman, R. and P. Mockapetris, "New DNS RR Definitions", RFC 1183, October 1990.
  • [23] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
  • [24] Floyd, S. and T. Henderson, "The NewReno Modification to TCP's Fast Recovery Algorithm", RFC 2582, April 1999.
  • [25] Floyd, S., Mahdavi, J., Mathis, M. and M. Podolsky, "An Extension to the Selective Acknowledgment (SACK) Option for TCP", RFC 2883, July 2000.
  • [26] Glass, S., Hiller, T., Jacobs, S. and C. Perkins, "Mobile IP Authentication, Authorization, and Accounting Requirements", RFC 2977, October 2000.
  • [27] Gulbrandsen, A. and P. Vixie, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2052, October 1996.
  • [28] Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service Location Protocol, Version 2", RFC 2608, June 1999.
  • [29] Hain, T., "Architectural Implications of NAT", RFC 2993, November 2000.
  • [30] Handley, M., Schulzrinne, H., Schooler, E., and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, March 1999.
  • [31] Holdrege, M. and P. Srisuresh, "Protocol Complications with the IP Network Address Translator (NAT)", Work in Progress.
  • [32] International Telecommunication Union. Visual Telephone Systems and Equipment for Local Area Networks which provide a Non-guaranteed Quality of Service. Recommendation H.323, May 1996.
  • [33] ISO/IEC. Protocol for Exchange of Inter-Domain Routeing Information among Intermediate Systems to support Forwarding of ISO 8473 PDUs. ISO/IEC IS10747, 1993.
  • [34] V. Jacobson. Congestion Avoidance and Control. Computer Communication Review, vol. 18, no. 4 August 1988. ftp://ftp.ee.lbl.gov/papers/congavoid.ps.Z.
  • [35] V. Jacobson. Modified TCP Congestion Avoidance Algorithm. end2end-interest mailing list, April 30, 1990. ftp://ftp.isi.edu/end2end/end2end-interest-1990.mail.
  • [36] Jacobson, V., Braden, R. and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992.
  • [37] Johnson, D. and C. Perkins, "Mobility Support in IPv6", Work in Progress.
  • [38] Jonsson, L., et al., "RObust Checksum-based header COmpression (ROCCO)", Work in Progress.
  • [39] Karn, P., et al., "Advice for Internet Subnetwork Designers", Work in Progress.
  • [40] King, S., et al., "The Case for IPv6", Work in Progress.
  • [41] J. Kulik, R. Coulter, D. Rockwell, and C. Partridge. Paced TCP for High Delay-Bandwidth Networks. Proceedings of IEEE Globecom '99, December 1999.
  • [42] Le, K., et al., "Adaptive Header ComprEssion (ACE) for Real-Time Multimedia", Work in Progress.
  • [43] Mathis, M., Mahdavi, J., Floyd, S. and A. Romanow, "TCP Selective Acknowledgment Options", RFC 2018, October 1996.
  • [44] Mockapetris, P., "Domain Names -- Concepts and Facilities", STD 13, RFC 1034, November 1987.
  • [45] Mockapetris, P., "Domain Names -- Implementation and Specification", STD 13, RFC 1035, November 1987.
  • [46] Nichols, K., Blake, S., Baker, F. and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
  • [47] Partridge, C., Mendez, T. and W. Milliken, "Host Anycasting Service", RFC 1546, November 1993.
  • [48] Perkins, C., "IP Mobility Support", RFC 2002, October 1996.
  • [49] Perkins, C. and P. Calhoun, "AAA Registration Keys for Mobile IP", Work in Progress.
  • [50] Perkins, C. and D. Johnson, "Route Optimization in Mobile IP", Work in Progress.
  • [51] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
  • [52] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
  • [53] Ramakrishnan, K. and S. Floyd, "A Proposal to add Explicit Congestion Notification (ECN) to IP", RFC 2481, January 1999.
  • [54] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995.
  • [55] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
  • [56] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote Authentication Dial In User Service (RADIUS)", RFC 2138, April 1997.
  • [57] Schulzrinne, H., Casner, S., Fredrick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996.
  • [58] J. Semke, J. Mahdavi, and M. Mathis. Automatic TCP Buffer Tuning. Proceedings of ACM SIGCOMM '98, September 1998.
  • [59] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999.
  • [60] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", Work in Progress.
  • [61] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000.
  • [62] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.
  • [63] Touch, J., "TCP Control Block Interdependence", RFC 2140, April 1997.
  • [64] Vollbrecht, J., et al., "AAA Authorization Framework", Work in Progress.

A Participants 💜

these are the lovely humans who helped make this happen, with their contact details exactly as listed 🌸

   Juha Ala-Laurila                JUHA.ALA-LAURILA@nokia.com
   Mark Allman                     mallman@grc.nasa.gov
   Alastair Angwin                 angwin@uk.ibm.com
   N. Asokan                       n.asokan@nokia.com
   Victor Bahl                     bahl@microsoft.com
   Fred Baker                      fred@cisco.com
   Pravin Bhagwat                  pravinb@us.ibm.com
   Scott Bradner                   sob@harvard.edu
   Randy Bush                      randy@psg.com
   Pat Calhoun                     Pcalhoun@eng.sun.com
   Brian Carpenter                 brian@icair.org
   Mikael Degermark                micke@cs.arizona.edu
   Sally Floyd                     floyd@aciri.org
   Heikki Hammainen                HEIKKI.HAMMAINEN@NOKIA.COM
   Mark Handley                    mjh@aciri.org
   Bob Hinden                      hinden@iprg.nokia.com
   Christian Huitema               huitema@microsoft.com
   Chih-Lin I                      ci@att.com
   Van Jacobson                    van@packetdesign.com
   Phil Karn                       Karn@qualcomm.com
   John Klensin                    Klensin@JCK.com
   Jerry Lahti                     jerry.lahti@nokia.com
   Allison Mankin                  mankin@isi.edu
   Danny J. Mitzel                 mitzel@iprg.nokia.com
   Gabriel Montenegro              gab@sun.com
   Keith Moore                     moore@cs.utk.edu
   Eric Nordmark                   nordmark@sun.com
   Charles E. Perkins              charliep@iprg.nokia.com
   Jonne Soininen                  jonna.Soininen@nokia.com
   Chris A. Wargo                  cwargo@cnsw.com
   Lars Westberg                   Lars.Westberg@era.ericsson.se
   Lixia Zhang                     lixia@cs.ucla.edu

B Author's Address 🎀

and here's where you can find the author, Danny J. Mitzel 🦋

   Danny J. Mitzel
   Nokia
   313 Fairchild Drive
   Mountain View, CA 94043
   USA

   Phone: +1 650 625 2037
   EMail: mitzel@iprg.nokia.com
the legal stuff, kept word for word so nothing gets lost in translation 🙈
   Copyright (C) The Internet Society (2000).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement 🫶

and last but not least, a big thank you: funding for the RFC Editor function is currently provided by the Internet Society 💖 that's a wrap, bestie ✨ periodt ✨

📦 where this page comes from