Internet DRAFT - draft-meng-tsvwg-wireless-collaboration
draft-meng-tsvwg-wireless-collaboration
TSVWG T. Meng
Internet-Draft H. Shi
Intended status: Informational Huawei Technologies
Expires: 25 April 2024 23 October 2023
Necessity of Application-Network Collaboration in Wireless Access
Scenarios
draft-meng-tsvwg-wireless-collaboration-00
Abstract
Emerging applications (e.g., extended reality, cloud gaming, and
teleoperation) impose stringent bandwidth, latency, reliability
requirements on network transport, so as to deliver immersive and
interactive user experience. That drives recent discussion on
application-network collaboration, especially in wireless access
networks. To motivate participation from content and network
providers, this memo elaborates the necessity of such collaboration
while focusing on wireless access scenarios.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 25 April 2024.
Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
Meng & Shi Expires 25 April 2024 [Page 1]
Internet-Draft App-Net Collaboration Necessity October 2023
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Importance of Wireless Access . . . . . . . . . . . . . . . . 3
4. Tradeoffs in Wireless Access Networks . . . . . . . . . . . . 3
4.1. Knobs to Compensate Wireless Losses . . . . . . . . . . . 3
4.2. Tradeoffs in Wireless QoS . . . . . . . . . . . . . . . . 4
5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 5
5.1. Collaboration May Not be a Zero-Sum Game . . . . . . . . 5
5.2. Why not Expose Wireless Losses to Transport Layer . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . 6
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
8. Reference . . . . . . . . . . . . . . . . . . . . . . . . . . 6
8.1. Normative References . . . . . . . . . . . . . . . . . . 6
8.2. Informative Reference . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
Thanks to performant congestion control and over-the-top
optimizations (e.g., jitter buffer), today's access network can
support rich Internet applications mostly using a single pervasive
QoS. Nevertheless, as emerging applications (e.g., extended reality,
cloud gaming, and teleoperation) keep pursuing immersive and
interactive user experience, the single pervasive network QoS starts
to be the bottleneck to fulfill their stringent requirements on
bandwidth, latency, and reliability at the same time
[I-D.ietf-mops-ar-use-case], especially in wireless access networks.
That drives discussion on application-network collaboration
[RFC9419]. Many recent proposals contribute to use cases and
solutions on how to accomplish collaborative signaling between
application endpoint and in-network element [I-D.joras-sadcdn]
[I-D.herbert-fast] [I-D.wing-cidfi]
[I-D.kaippallimalil-tsvwg-media-hdr-wireless]
[I-D.shi-quic-structured-connection-id]. To motivate participation
from content and network providers, this memo elaborates the
necessity of such collaboration while focusing on wireless access
scenarios.
Meng & Shi Expires 25 April 2024 [Page 2]
Internet-Draft App-Net Collaboration Necessity October 2023
2. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. Importance of Wireless Access
Stringent latency requirements of emerging applications require edge
deployment, making highly fluctuating wireless access links one of
the main bottlenecks in user-facing last-mile transport.
[Details will be added later.]
4. Tradeoffs in Wireless Access Networks
4.1. Knobs to Compensate Wireless Losses
The most important characteristic that distinguishes wireless access
networks from wired networks is the inherently unreliable
communication media. L2 packet losses on a wireless access link must
be much more common than on a wired link. To compensate wireless
losses and achieve a practical low loss rate (e.g., below 1%) at
transport layer and above, wireless networks can manipulate several
knobs, as exemplified below. However, they inevitably come with
tradeoffs.
* Modulation and Coding Scheme (MCS): Adopting a lower-order
modulation (e.g., 16QAM instead of 64QAM) and adding more
redundancy (e.g., a lower FEC code rate) can increase wireless
transmission reliability and contribute to more consistent
latency. However, that impact wireless spectral efficiency, and
degrade the bandwidth upper limit (i.e., a lower-order modulation
transmits less bits per symbol).
* L2 retransmission: This is the most popular way to cover up WiFi
and cellular L2 losses. To some extent, it is the outcome of
early-day TCP's inability to resist non-congestive losses.
Although L2 retransmissions are critical for many congestion
control algorithms to fully utilize available wireless bandwidth
(some are even still quite popular nowadays, such as CUBIC and
Prague), yet they cause high tail latency.
Meng & Shi Expires 25 April 2024 [Page 3]
Internet-Draft App-Net Collaboration Necessity October 2023
* L2 reordering: Wireless networks such as LTE and 5G also conduct
packet reordering together with L2 retransmissions, for purpose of
in-order delivery to transport layer. However, upon L2 packet
loss, that also blocks subsequent received transport blocks in a
low-layer reordering buffer, further deteriorating tail latency.
4.2. Tradeoffs in Wireless QoS
Without collaborative signaling between application and network,
network is expected to mostly provide a single pervasive transport
service to heterogeneous data from possibly many different
applications. Such a coarse-granularity QoS should be determined by
the highest requirements on each performance indicators. For
example, ultra-high bandwidth is needed to accommodate ultra-high
definition virtual reality media, ultra-low latency is needed to
realize close to real-time motion-to-photon gaming latency, and
ultra-high reliability is needed to deliver remote teleoperation
instructions. Nevertheless, a individual wireless QoS is
bottlenecked by the unreliable communication media.
Table 1 shows the corresponding configuration of the above knobs to
guarantee an individual QoS indicator.
+============================+===================================+
| QoS Objective | Knob Configurations |
+============================+===================================+
| High bandwidth | High-order MCS |
| | |
| (high spectral efficiency) | |
+----------------------------+-----------------------------------+
| Consistently low latency | Less or no L2 retransmission, no |
| | reordering |
+----------------------------+-----------------------------------+
| Low loss, high reliability | Low-order MCS, or |
| | |
| | L2 retransmission with reordering |
+----------------------------+-----------------------------------+
Table 1: Configurations Corresponding to Individual QoS Indicator
According to the table, there is Figure 1 showing the tradeoff
relations between three QoS indicators. It is quite challenging, if
not impossible, for wireless access networks to efficiently provide a
pervasive QoS that fulfills ultra high bandwidth, ultra-low latency,
and ultra-high reliability at the same time.
Meng & Shi Expires 25 April 2024 [Page 4]
Internet-Draft App-Net Collaboration Necessity October 2023
+----------------+
+-----| High Bandwidth |-------+
| +----------------+ |
High-Order MCS | | High-Order MCS
No L2 Retrans. | | L2 Retrans. w/
No Reordering | | L2 Reordering
| |
+------+------+ +-----+-----+
| Low Latency |-----------------| Low Loss |
+-------------+ Low-Order MCS +-----------+
No L2 Retrans.
No Reordering
Figure 1: Tradeoffs between QoS Indicators
The currently off-the-shelf LTE and 5G adopt high-order MCS for high
spectral efficiency, and enable both L2 retransmission and reordering
to guarantee very low transport-layer packet loss rate. Although
contemporary real-time communication (RTC) applications such as video
conferencing managed to scale with performant congestion control and
over-the-top optimizations (e.g., jitter buffer), emerging immersive
applications requiring ultra-low latency (e.g., below 50 ms) will be
impeded by the inherent tail latency (e.g., could exceed 100 ms
[TailLatency]).
5. Discussion
5.1. Collaboration May Not be a Zero-Sum Game
Packet prioritization or stream/flow QoS multiplexing is necessary to
handle the tradeoffs resulted from unreliable wireless communication
media. That involves collaborative signaling between application and
network. This memo notes that application-network collaboration is
not necessarily a zero-sum game. That is the case when the wireless
access network serves different flows only by tailored configurations
of above knobs, without prioritized resource allocation. For
example, a low latency flow without L2 retransmissions may not
sacrifice the available bandwidth of another classic flow enabling
both L2 retransmission and reordering, as long as they run on
wireless bearers with fair time/frequency domain resources.
5.2. Why not Expose Wireless Losses to Transport Layer
One may argue that recent transport protocols such as QUIC [RFC9000]
can handle lost and out-of-order packets well, so that L2
retransmission and reordering can be disabled for all traffic to
avoid explicit application-network collaboration. This memo
validates those knobs as follows.
Meng & Shi Expires 25 April 2024 [Page 5]
Internet-Draft App-Net Collaboration Necessity October 2023
* Compared with end-to-end retransmission, local L2 retransmission
is more efficient. The former adds at least one RTT that is tens
of milliseconds, while the later only needs several milliseconds
or even lower depending on radio technologies. Such a difference
is crucial for ultra-low latency.
* Exposing L2 wireless losses to endpoint confuses recognition of
congestion. Out of spectral efficiency, cellular networks usually
set the target L2 block error rate to 10% by default. An
equivalent loss rate at transport layer, along with frequent out-
of-order arrivals, can complicate congestion control, especially
when considering the stringent application requirements.
6. Security Considerations
Tba.
7. IANA Considerations
This memo has no IANA actions.
8. Reference
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport", RFC 9000,
DOI 10.17487/RFC9000, May 2021,
<https://www.rfc-editor.org/info/rfc9000>.
[RFC9419] Arkko, J., Hardie, T., Pauly, T., and M. Kühlewind,
"Considerations on Application - Network Collaboration
Using Path Signals", RFC 9419, DOI 10.17487/RFC9419, July
2023, <https://www.rfc-editor.org/info/rfc9419>.
Meng & Shi Expires 25 April 2024 [Page 6]
Internet-Draft App-Net Collaboration Necessity October 2023
[I-D.herbert-fast]
Herbert, T., "Firewall and Service Tickets", Work in
Progress, Internet-Draft, draft-herbert-fast-07, 7 October
2023, <https://datatracker.ietf.org/doc/html/draft-
herbert-fast-07>.
[I-D.wing-cidfi]
Wing, D., Reddy.K, T., and M. Boucadair, "CID Flow
Indicator (CIDFI)", Work in Progress, Internet-Draft,
draft-wing-cidfi-02, 12 September 2023,
<https://datatracker.ietf.org/doc/html/draft-wing-cidfi-
02>.
[I-D.kaippallimalil-tsvwg-media-hdr-wireless]
Kaippallimalil, J., Gundavelli, S., and S. Dawkins, "Media
Header Extensions for Wireless Networks", Work in
Progress, Internet-Draft, draft-kaippallimalil-tsvwg-
media-hdr-wireless-03, 16 October 2023,
<https://datatracker.ietf.org/doc/html/draft-
kaippallimalil-tsvwg-media-hdr-wireless-03>.
[I-D.shi-quic-structured-connection-id]
Shi, H., "Structured Connection ID Carrying Metadata",
Work in Progress, Internet-Draft, draft-shi-quic-
structured-connection-id-01, 12 September 2023,
<https://datatracker.ietf.org/doc/html/draft-shi-quic-
structured-connection-id-01>.
8.2. Informative Reference
[I-D.ietf-mops-ar-use-case]
Krishna, R. and A. Rahman, "Media Operations Use Case for
an Extended Reality Application on Edge Computing
Infrastructure", Work in Progress, Internet-Draft, draft-
ietf-mops-ar-use-case-13, 22 October 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-mops-ar-
use-case-13>.
[I-D.joras-sadcdn]
Joras, M., "Securing Ancillary Data for Communicating with
Devices in the Network", Work in Progress, Internet-Draft,
draft-joras-sadcdn-01, 10 July 2023,
<https://datatracker.ietf.org/doc/html/draft-joras-sadcdn-
01>.
[TailLatency]
Meng, Z., Guo, Y., Sun, C., Wang, B., Sherry, J., Liu, H.,
and M. Xu, "Achieving Consistent Low Latency for Wireless
Meng & Shi Expires 25 April 2024 [Page 7]
Internet-Draft App-Net Collaboration Necessity October 2023
Real-Time Communications with the Shortest Control Loop",
SIGCOMM 2022, DOI 10.1145/3544216.3544225, 2022,
<https://dl.acm.org/doi/10.1145/3544216.3544225>.
Authors' Addresses
Tong Meng
Huawei Technologies
China
Email: mengtong1@huawei.com
Hang Shi
Huawei Technologies
China
Email: shihang9@huawei.com
Meng & Shi Expires 25 April 2024 [Page 8]
