<?xml version='1.0' encoding='utf-8'?>
<?rfc toc='yes'?>
<?rfc compact='yes'?>
<?rfc subcompact='no'?>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude"
     xml:lang="en"
     ipr="trust200902"
     submissionType="IETF"
     consensus="true"
     category="info"
     docName="draft-meng-tsvwg-wireless-collaboration-00"
     updates=""
     version="3">

  <front>
    <title abbrev="App-Net Collaboration Necessity">Necessity of Application-Network Collaboration in Wireless Access Scenarios</title>
    <seriesInfo name="Internet-Draft" value="draft-meng-tsvwg-wireless-collaboration-00"/>


    <author fullname="Tong Meng" initials="T" surname="Meng">
      <organization>Huawei Technologies</organization>
      <address>
        <postal>
          <country>CN</country>
        </postal>
        <email>mengtong1@huawei.com</email>
      </address>
    </author>

    <author fullname="Hang Shi" initials="H" surname="Shi">
      <organization>Huawei Technologies</organization>
      <address> <!-- https://authors.ietf.org/en/rfcxml-vocabulary#address -->
        <postal>
          <country>CN</country>
        </postal>
        <email>shihang9@huawei.com</email>
      </address>
    </author>

    <date />

    <area>Transport</area>
    <workgroup>TSVWG</workgroup>
    <keyword>Application-Network Collaboration</keyword>

    <abstract>
      <t>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.</t>
    </abstract>
  </front>

  <middle>
    <section anchor='introduction'>
      <name>Introduction</name>
      <t>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 <xref target="I-D.ietf-mops-ar-use-case"/>, especially in wireless access networks. That drives discussion on application-network collaboration <xref target="RFC9419"/>. Many recent proposals contribute to use cases and solutions on how to accomplish collaborative signaling between application endpoint and in-network element <xref target="I-D.joras-sadcdn"/> <xref target="I-D.herbert-fast"/> <xref target="I-D.wing-cidfi"/> <xref target="I-D.kaippallimalil-tsvwg-media-hdr-wireless"/> <xref target="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.</t>
    </section>

    <section anchor='conventions'>
      <name>Conventions</name>
      <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shown here.</t>
    </section>

    <section anchor='wirelessimportance'>
      <name>Importance of Wireless Access</name>
      <t>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.</t>
      <t>[Details will be added later.]</t>
    </section>

    <section anchor="wirelesstradeoff">
      <name>Tradeoffs in Wireless Access Networks</name>

      <section anchor="knobs">
        <name>Knobs to Compensate Wireless Losses</name>
        <t>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.</t>

        <ul>
          <li><t>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).</t></li>
          <li><t>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.</t></li>
          <li><t>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.</t></li>
        </ul>
      </section>

      <section anchor="tradeoff">
        <name>Tradeoffs in Wireless QoS</name>
        <t>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.</t>

        <t><xref target="knobsconfiguration"/> shows the corresponding configuration of the above knobs to guarantee an individual QoS indicator.</t>

        <table anchor="knobsconfiguration" align="center">
          <name>Configurations Corresponding to Individual QoS Indicator</name>
          <thead>
            <tr><th>QoS Objective</th><th>Knob Configurations</th></tr>
          </thead>
          <tbody>
            <tr><td><t>High bandwidth </t><t>(high spectral efficiency)</t></td><td>High-order MCS</td></tr>
            <tr><td>Consistently low latency</td><td>Less or no L2 retransmission, no reordering</td></tr>
            <tr><td>Low loss, high reliability</td><td><t>Low-order MCS, or</t><t>L2 retransmission with reordering</t></td></tr>
          </tbody>
        </table>

        <t>According to the table, there is <xref target="qostriangle"/> 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.</t>

        <figure anchor="qostriangle">
          <name>Tradeoffs between QoS Indicators</name>
          <artwork align="center">
                     +----------------+
               +-----| 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
          </artwork>
        </figure>

        <t>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 <xref target="TailLatency"/>).</t>
      </section>
    </section>

    <section anchor="discussion">
      <name>Discussion</name>

      <section anchor="zerosum">
        <name>Collaboration May Not be a Zero-Sum Game</name>
        <t>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.</t>
      </section>

      <section anchor="exposeloss">
        <name>Why not Expose Wireless Losses to Transport Layer</name>
        <t>One may argue that recent transport protocols such as QUIC <xref target="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.</t>

        <ul>
          <li><t>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.</t></li>
          <li><t>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.</t></li>
        </ul>

        <!-- <t>In fact, even if a unified transport protocol such as QUIC is used, different applications' flavor on reliability versus latency sensitivity varies. A single wireless configuration for all may not be the most appropriate for wireless spectral efficiency and application development complexity. [However, the editors admit this is an open question and needs further discussion.]</t> -->
      </section>
    </section>

    <section anchor="security">
      <name>Security Considerations</name>
      <t>Tba.</t>
    </section>

    <section anchor="iana">
      <name>IANA Considerations</name>
      <t>This memo has no IANA actions.</t>
    </section>
  </middle>

  <back>
    <references>
      <name>Reference</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.9000.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.9419.xml"/>

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.herbert-fast.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.wing-cidfi.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.kaippallimalil-tsvwg-media-hdr-wireless.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.shi-quic-structured-connection-id.xml"/>
      </references>

      <references>
        <name>Informative Reference</name>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-mops-ar-use-case.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.joras-sadcdn.xml"/>

        <reference anchor="TailLatency" target="https://dl.acm.org/doi/10.1145/3544216.3544225">
            <front>
              <title>Achieving Consistent Low Latency for Wireless Real-Time Communications with the Shortest Control Loop</title>
              <author initials="Z." surname="Meng"><organization/></author>
              <author initials="Y." surname="Guo"><organization/></author>
              <author initials="C." surname="Sun"><organization/></author>
              <author initials="B." surname="Wang"><organization/></author>
              <author initials="J." surname="Sherry"><organization/></author>
              <author initials="H." surname="Liu"><organization/></author>
              <author initials="M." surname="Xu"><organization/></author>
              <date year="2022"/>
            </front>
            <seriesInfo name="SIGCOMM" value="2022"/>
            <seriesInfo name="DOI" value="10.1145/3544216.3544225"/>
          </reference>
      </references>
    </references>
  </back>
</rfc>
