rfc3002.txt

Overview of 2000 IAB Wireless Internetworking Workshop

   congestion control is not optional when using rate adaptive transport
   protocols.

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

3.4.3 Discussion on IETF Transport Activities

   Discussion on transport work in the IETF presented a large array of
   activities.  Recent work on transport improvement includes path MTU,
   Forward Error Correction (FEC), large windows, SACK, NewReno Fast
   Recovery, ACK congestion control, segment byte counting, Explicit
   Congestion Notification (ECN), larger initial transmit windows, and



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


   sharing of related TCP connection state [3,4,5,6,24,25,43,53,63].
   Work on new transports includes SCTP [61] in the IETF Signaling
   Transport (sigtran) working group and TCP-Friendly Rate Control
   (TFRC) [1] by researchers at ACIRI.  SCTP provides a reliable UDP-
   like protocol supporting persistent associations and in-order
   delivery with congestion control.  TFRC is targeted at unreliable,
   unicast streaming media.  Finally, work in the IETF End-point
   Congestion Management (ecm) working group is looking at standardizing
   congestion control algorithms, and work in the Performance
   Implications of Link Characteristics (pilc) working group is
   characterizing performance impacts of various link technologies and
   investigating performance improvements.

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

3.5 Discussion on Aeronautical Telecommunication Network (ATN) Routing
    Policy

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

   Current ATN views each aircraft as an autonomous network (AS) with
   changing point of attachment as it "roams" through different
   airspace.  Addressing information associated with the aircraft is
   fixed, which makes route aggregation difficult since they're not
   related to topology, and also increases the frequency of updates.
   Additionally, the aircraft may be multiply attached (within coverage



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


   of multiple ground and space-based access networks), requiring
   routing policy support for path selection.  Finally, QoS path
   selection capabilities may be beneficial to arbitrate shared access
   or partition real-time control traffic from other data traffic.

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

3.6 Discussion on QoS Services

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

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

3.6.1 Discussion on "Last Leg" QoS

   Discussion on voice over IP (VoIP) emphasized that (wireless) access
   link is typically the most constrained resource, and while contention
   access (CSMA) provides good utilization for data it is not ideal for
   voice.  Two models were identified as potential solution in VoIP
   architecture.  The first is to have the wireless device directly
   signal the local access router.  A second alternative is to have the



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


   call control element (SIP agent [30]) "program" the edge router.
   This tradeoff seemed to be an area open for additional investigation,
   especially given the complications that may be introduced in the face
   of mobility and roaming handoffs.  This appears a key component to
   solve for success in VoIP adoption.

   Work within the IEEE 802.11 WLAN group identified similar
   requirements for QoS support.  That group is investigating a model
   employing two transmission queues, one for realtime and one for
   best-effort traffic.  Additional plans include mapping between IP
   DiffServ markings [14,46] and IEEE 802 priorities.

   The statement was also made that QoS over the wireless link is not
   the fundamental problem, rather it is handling mobility aspects and
   seamless adaptation across handoffs without service disruption.
   There were concerns about mechanisms establishing per-flow state
   (RSVP [13]).  Issues include scaling of state, and signaling overhead
   and setup delays on roaming events.  DiffServ [9] approach allows
   allocating QoS for aggregate traffic class, which simplifies roaming.
   However, DiffServ requires measurement and allocation adjustment over
   time, and policing to limit amount of QoS traffic injected.

3.6.2 Discussion on Path QoS Discovery

   The HDR high speed wireless packet data system under development at
   Qualcomm highlights unique characteristics of some wireless media.
   This system provides users a channel rate between 38.4Kb/s and
   2.4Mb/s, with throughput dependent on channel loading and distance
   from network access point.  This gave rise to considerable discussion
   on whether it might be possible to discover and provide feedback to
   the application regarding current link or path QoS being received.
   This might enable some form of application adaptation.

   In the case of the HDR system it was indicated that no such feedback
   is currently available.  Additionally, it was argued that this is in
   accord with the current Internet stack model, which does not provide
   any mechanisms to expose this type of information.  Counter arguments
   stated that there are growing demands in Internet QoS working groups
   requesting exposure of this type of information via standardized
   APIs.  Members working on GPRS protocols also indicated frustration
   in deploying QoS capabilities without exposure of this information.
   This clearly seemed a topic for further investigations.

   A final area of discussion on QoS discovery focused on the question
   of how a server application might find out the capabilities of a
   receiver.  This could allow for application adaptation to client
   device and path characteristics.  One suggestion proposed use of RSVP
   payload, which is able to transport QoS information.  A second



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


   alternative is to push capability exchange and negotiation to the
   application layer.  Discussion on this topic was brief, as
   application issues were deemed outside the workshop charter, however
   this also seems an area open for future investigation.

3.7 Discussion on Header Compression

   A critical deterrent to Internet protocol adoption in the highly
   band-width constrained wireless cellular environment is the bit
   overhead of the protocol encoding.  Examples presented highlighted
   how a voice application (layered over IP [52,19], UDP [51], and RTP
   [57]) requires a minimum of 40 bytes of headers for IPv4 or 60 bytes
   for IPv6 before any application payload (e.g., 24 byte voice sample).
   This overhead was also presented as a contributing factor for the
   creation of WAP Wireless Datagram Protocol (WDP) rather than IP for
   very low datarate bearers.

   Discussion on header compression techniques to alleviate these
   concerns focused on work being performed within the IETF Robust
   Header Compression (rohc) working group.  This working group has
   established goals for wireless environment, to conserve radio
   spectrum, to accommodate mobility, and to be robust to packet loss
   both before the point where compression is applied and between
   compressor and decompressor.  Additional requirements established
   were that the technique be transparent, does not introduce additional
   errors, and that it is compatible with common protocol layerings
   (e.g., IPv4, IPv6, RTP/UDP/IP, TCP/IP).

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

   A detriment to IPv6 adoption often cited is its additional header
   overhead, primarily attributed to its larger address size.  A
   secondary observation made was that it's believed that IPv6
   accommodates greater header compression than IPv4.  This was
   attributed to the elimination of the checksum and identification
   fields from the header.

   Discussion on use of WWW protocols over wireless highlighted protocol
   encodings as another potential detriment to their adoption.  A number
   of alternatives were mentioned for investigation, including use of a
   "deflate" Content-Encoding, using compression with TLS [20], or



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


   Bellovin's TCP filters.  Observation was made that it could be
   beneficial to investigate more compact alternative encoding of the
   WWW protocols.

3.8 Discussion on Applications Protocols

   IETF protocol developments have traditionally taken the approach of
   preferring simple encode/decode and word alignment at the cost of
   some extra bit transmissions.  It was stated that optimizing protocol
   encoding for bit savings often leads to shortcomings or limitations
   on protocol evolution.  However, it was also argued that environments
   where physical limitations have an effect on transmission capacity
   and system performance may present exceptions where optimized
   encodings are beneficial.  Cellular wireless and near-space satellite
   may fall into this category.

   The WAP protocols exhibit several examples where existing Internet
   protocols were felt to be too inefficient for adoption with very low
   datarate bearer services and limited capability devices.  The WAP
   Wireless Session Protocol (WSP) is based on HTTPv1.1 [23], however
   WSP incorporates several changes to address perceived inefficiencies.
   WSP uses a more compact binary header encoding and optimizations for
   efficient connection and capability negotiation.  Similarly, the WAP
   Wireless Application Environment (WAE) uses tokenized WML and a tag-
   based browser environment for more efficient operation.

   Additional requests for more efficient and compact protocol
   encodings, and especially improved capability negotiation were raised
   during discussion on usage of WWW protocols with wireless handheld
   devices.

   Finally, work within the near-space satellite environment has pointed
   out other physical limitations that can affect performance.  In this
   case the long propagation delays can make "chatty" protocols highly
   inefficient and unbearable for interactive use.  This environment
   could benefit from protocols that support some form of "pipelining"
   operation.