├── .circleci └── config.yml ├── .github ├── CODEOWNERS └── workflows │ ├── archive.yml │ ├── ghpages.yml │ ├── publish.yml │ └── update.yml ├── .gitignore ├── .gitmodules ├── .note.xml ├── CONTRIBUTING.md ├── LICENSE.md ├── Makefile ├── README.md └── draft-ietf-avtcore-rtp-over-quic.md /.circleci/config.yml: -------------------------------------------------------------------------------- 1 | version: 2 2 | jobs: 3 | build: 4 | docker: 5 | - image: martinthomson/i-d-template:latest 6 | working_directory: ~/draft 7 | 8 | steps: 9 | - run: 10 | name: "Print Configuration" 11 | command: | 12 | xml2rfc --version 13 | gem list -q kramdown-rfc2629 14 | echo -n 'mmark '; mmark --version 15 | 16 | - restore_cache: 17 | name: "Restoring cache - Git" 18 | keys: 19 | - v2-cache-git-{{ .Branch }}-{{ .Revision }} 20 | - v2-cache-git-{{ .Branch }} 21 | - v2-cache-git- 22 | 23 | - restore_cache: 24 | name: "Restoring cache - References" 25 | keys: 26 | - v1-cache-references-{{ epoch }} 27 | - v1-cache-references- 28 | 29 | # Workaround for https://discuss.circleci.com/t/22437 30 | - run: 31 | name: Tag Checkout 32 | command: | 33 | if [ -n "$CIRCLE_TAG" ] && [ -d .git ]; then 34 | remote=$(echo "$CIRCLE_REPOSITORY_URL" | \ 35 | sed -e 's,/^git.github.com:,https://github.com/,') 36 | git fetch -f "$remote" "refs/tags/$CIRCLE_TAG:refs/tags/$CIRCLE_TAG" || \ 37 | (echo 'Removing .git cache for tag build'; rm -rf .git) 38 | fi 39 | 40 | - checkout 41 | 42 | # Build txt and html versions of drafts 43 | - run: 44 | name: "Build Drafts" 45 | command: "make 'CLONE_ARGS=--reference ~/git-reference'" 46 | 47 | # Update editor's copy on gh-pages 48 | - run: 49 | name: "Update GitHub Pages" 50 | command: | 51 | if [ "${CIRCLE_TAG#draft-}" == "$CIRCLE_TAG" ]; then 52 | make gh-pages 53 | fi 54 | 55 | # For tagged builds, upload to the datatracker. 56 | - deploy: 57 | name: "Upload to Datatracker" 58 | command: | 59 | if [ "${CIRCLE_TAG#draft-}" != "$CIRCLE_TAG" ]; then 60 | make upload 61 | fi 62 | 63 | # Archive GitHub Issues 64 | - run: 65 | name: "Archive GitHub Issues" 66 | command: "make archive || make archive DISABLE_ARCHIVE_FETCH=true && make gh-archive" 67 | 68 | # Create and store artifacts 69 | - run: 70 | name: "Create Artifacts" 71 | command: "make artifacts CI_ARTIFACTS=/tmp/artifacts" 72 | 73 | - store_artifacts: 74 | path: /tmp/artifacts 75 | 76 | - run: 77 | name: "Prepare for Caching" 78 | command: "git reflog expire --expire=now --all && git gc --prune=now" 79 | 80 | - save_cache: 81 | name: "Saving Cache - Git" 82 | key: v2-cache-git-{{ .Branch }}-{{ .Revision }} 83 | paths: 84 | - ~/draft/.git 85 | 86 | - save_cache: 87 | name: "Saving Cache - Drafts" 88 | key: v1-cache-references-{{ epoch }} 89 | paths: 90 | - ~/.cache/xml2rfc 91 | 92 | 93 | workflows: 94 | version: 2 95 | build: 96 | jobs: 97 | - build: 98 | filters: 99 | tags: 100 | only: /.*?/ 101 | -------------------------------------------------------------------------------- /.github/CODEOWNERS: -------------------------------------------------------------------------------- 1 | # Automatically generated CODEOWNERS 2 | # Regenerate with `make update-codeowners` 3 | draft-ietf-avtcore-rtp-over-quic.md mathis.engelbart@gmail.com ott@in.tum.de spencerdawkins.ietf@gmail.com 4 | -------------------------------------------------------------------------------- /.github/workflows/archive.yml: -------------------------------------------------------------------------------- 1 | name: "Archive Issues and Pull Requests" 2 | 3 | on: 4 | schedule: 5 | - cron: '0 0 * * 0,2,4' 6 | repository_dispatch: 7 | types: [archive] 8 | workflow_dispatch: 9 | inputs: 10 | archive_full: 11 | description: 'Recreate the archive from scratch' 12 | default: false 13 | type: boolean 14 | 15 | jobs: 16 | build: 17 | name: "Archive Issues and Pull Requests" 18 | runs-on: ubuntu-latest 19 | permissions: 20 | contents: write 21 | steps: 22 | - name: "Checkout" 23 | uses: actions/checkout@v4 24 | 25 | # Note: No caching for this build! 26 | 27 | - name: "Update Archive" 28 | uses: martinthomson/i-d-template@v1 29 | env: 30 | ARCHIVE_FULL: ${{ inputs.archive_full }} 31 | with: 32 | make: archive 33 | token: ${{ github.token }} 34 | 35 | - name: "Update GitHub Pages" 36 | uses: martinthomson/i-d-template@v1 37 | with: 38 | make: gh-archive 39 | token: ${{ github.token }} 40 | 41 | - name: "Save Archive" 42 | uses: actions/upload-artifact@v4 43 | with: 44 | path: archive.json 45 | -------------------------------------------------------------------------------- /.github/workflows/ghpages.yml: -------------------------------------------------------------------------------- 1 | name: "Update Editor's Copy" 2 | 3 | on: 4 | push: 5 | paths-ignore: 6 | - README.md 7 | - CONTRIBUTING.md 8 | - LICENSE.md 9 | - .gitignore 10 | pull_request: 11 | paths-ignore: 12 | - README.md 13 | - CONTRIBUTING.md 14 | - LICENSE.md 15 | - .gitignore 16 | 17 | jobs: 18 | build: 19 | name: "Update Editor's Copy" 20 | runs-on: ubuntu-latest 21 | permissions: 22 | contents: write 23 | steps: 24 | - name: "Checkout" 25 | uses: actions/checkout@v4 26 | 27 | - name: "Setup" 28 | id: setup 29 | run: date -u "+date=%FT%T" >>"$GITHUB_OUTPUT" 30 | 31 | - name: "Caching" 32 | uses: actions/cache@v4 33 | with: 34 | path: | 35 | .refcache 36 | .venv 37 | .gems 38 | node_modules 39 | .targets.mk 40 | key: i-d-${{ steps.setup.outputs.date }} 41 | restore-keys: i-d- 42 | 43 | - name: "Build Drafts" 44 | uses: martinthomson/i-d-template@v1 45 | with: 46 | token: ${{ github.token }} 47 | 48 | - name: "Update GitHub Pages" 49 | uses: martinthomson/i-d-template@v1 50 | if: ${{ github.event_name == 'push' }} 51 | with: 52 | make: gh-pages 53 | token: ${{ github.token }} 54 | 55 | - name: "Archive Built Drafts" 56 | uses: actions/upload-artifact@v4 57 | with: 58 | path: | 59 | draft-*.html 60 | draft-*.txt 61 | -------------------------------------------------------------------------------- /.github/workflows/publish.yml: -------------------------------------------------------------------------------- 1 | name: "Publish New Draft Version" 2 | 3 | on: 4 | push: 5 | tags: 6 | - "draft-*" 7 | workflow_dispatch: 8 | inputs: 9 | email: 10 | description: "Submitter email" 11 | default: "" 12 | type: string 13 | 14 | jobs: 15 | build: 16 | name: "Publish New Draft Version" 17 | runs-on: ubuntu-latest 18 | steps: 19 | - name: "Checkout" 20 | uses: actions/checkout@v4 21 | 22 | # See https://github.com/actions/checkout/issues/290 23 | - name: "Get Tag Annotations" 24 | run: git fetch -f origin ${{ github.ref }}:${{ github.ref }} 25 | 26 | - name: "Setup" 27 | id: setup 28 | run: date -u "+date=%FT%T" >>"$GITHUB_OUTPUT" 29 | 30 | - name: "Caching" 31 | uses: actions/cache@v4 32 | with: 33 | path: | 34 | .refcache 35 | .venv 36 | .gems 37 | node_modules 38 | .targets.mk 39 | key: i-d-${{ steps.setup.outputs.date }} 40 | restore-keys: i-d- 41 | 42 | - name: "Build Drafts" 43 | uses: martinthomson/i-d-template@v1 44 | with: 45 | token: ${{ github.token }} 46 | 47 | - name: "Upload to Datatracker" 48 | uses: martinthomson/i-d-template@v1 49 | with: 50 | make: upload 51 | env: 52 | UPLOAD_EMAIL: ${{ inputs.email }} 53 | 54 | - name: "Archive Submitted Drafts" 55 | uses: actions/upload-artifact@v4 56 | with: 57 | path: "versioned/draft-*-[0-9][0-9].*" 58 | -------------------------------------------------------------------------------- /.github/workflows/update.yml: -------------------------------------------------------------------------------- 1 | name: "Update Generated Files" 2 | # This rule is not run automatically. 3 | # It can be run manually to update all of the files that are part 4 | # of the template, specifically: 5 | # - README.md 6 | # - CONTRIBUTING.md 7 | # - .note.xml 8 | # - .github/CODEOWNERS 9 | # - Makefile 10 | # 11 | # 12 | # This might be useful if you have: 13 | # - added, removed, or renamed drafts (including after adoption) 14 | # - added, removed, or changed draft editors 15 | # - changed the title of drafts 16 | # 17 | # Note that this removes any customizations you have made to 18 | # the affected files. 19 | on: workflow_dispatch 20 | 21 | jobs: 22 | build: 23 | name: "Update Files" 24 | runs-on: ubuntu-latest 25 | steps: 26 | - name: "Checkout" 27 | uses: actions/checkout@v4 28 | 29 | - name: "Update Generated Files" 30 | uses: martinthomson/i-d-template@v1 31 | with: 32 | make: update-files 33 | token: ${{ github.token }} 34 | 35 | - name: "Push Update" 36 | run: git push 37 | -------------------------------------------------------------------------------- /.gitignore: -------------------------------------------------------------------------------- 1 | *~ 2 | /*-[0-9][0-9].xml 3 | archive.json 4 | draft-ietf-avtcore-rtp-over-quic.xml 5 | Gemfile.lock 6 | /.gems/ 7 | *.html 8 | /lib 9 | /.*.mk 10 | /node_modules/ 11 | package-lock.json 12 | *.pdf 13 | *.redxml 14 | /.refcache 15 | report.xml 16 | *.swp 17 | .tags 18 | *.txt 19 | *.upload 20 | /.venv/ 21 | /versioned/ 22 | /.vscode/ 23 | !requirements.txt 24 | -------------------------------------------------------------------------------- /.gitmodules: -------------------------------------------------------------------------------- 1 | [submodule "lib"] 2 | path = lib 3 | url = https://github.com/martinthomson/i-d-template 4 | -------------------------------------------------------------------------------- /.note.xml: -------------------------------------------------------------------------------- 1 | 2 | Discussion of this document takes place on the 3 | Audio/Video Transport Core Maintenance Working Group mailing list (avt@ietf.org), 4 | which is archived at . 5 | Source for this draft and an issue tracker can be found at 6 | . 7 | 8 | -------------------------------------------------------------------------------- /CONTRIBUTING.md: -------------------------------------------------------------------------------- 1 | # Contributing 2 | 3 | This repository relates to activities in the Internet Engineering Task Force 4 | ([IETF](https://www.ietf.org/)). All material in this repository is considered 5 | Contributions to the IETF Standards Process, as defined in the intellectual 6 | property policies of IETF currently designated as 7 | [BCP 78](https://www.rfc-editor.org/info/bcp78), 8 | [BCP 79](https://www.rfc-editor.org/info/bcp79) and the 9 | [IETF Trust Legal Provisions (TLP) Relating to IETF Documents](http://trustee.ietf.org/trust-legal-provisions.html). 10 | 11 | Any edit, commit, pull request, issue, comment or other change made to this 12 | repository constitutes Contributions to the IETF Standards Process 13 | (https://www.ietf.org/). 14 | 15 | You agree to comply with all applicable IETF policies and procedures, including, 16 | BCP 78, 79, the TLP, and the TLP rules regarding code components (e.g. being 17 | subject to a Simplified BSD License) in Contributions. 18 | 19 | 20 | ## Working Group Information 21 | 22 | Discussion of this work occurs on the [Audio/Video Transport Core Maintenance 23 | Working Group mailing list](mailto:avt@ietf.org) 24 | ([archive](https://mailarchive.ietf.org/arch/browse/avt/), 25 | [subscribe](https://www.ietf.org/mailman/listinfo/avt)). 26 | In addition to contributions in GitHub, you are encouraged to participate in 27 | discussions there. 28 | 29 | **Note**: Some working groups adopt a policy whereby substantive discussion of 30 | technical issues needs to occur on the mailing list. 31 | 32 | You might also like to familiarize yourself with other 33 | [Working Group documents](https://datatracker.ietf.org/wg/avtcore/documents/). 34 | -------------------------------------------------------------------------------- /LICENSE.md: -------------------------------------------------------------------------------- 1 | # License 2 | 3 | See the 4 | [guidelines for contributions](https://github.com/ietf-wg-avtcore/draft-ietf-avtcore-rtp-over-quic/blob/main/CONTRIBUTING.md). 5 | -------------------------------------------------------------------------------- /Makefile: -------------------------------------------------------------------------------- 1 | LIBDIR := lib 2 | include $(LIBDIR)/main.mk 3 | 4 | $(LIBDIR)/main.mk: 5 | ifneq (,$(shell grep "path *= *$(LIBDIR)" .gitmodules 2>/dev/null)) 6 | git submodule sync 7 | git submodule update --init 8 | else 9 | ifneq (,$(wildcard $(ID_TEMPLATE_HOME))) 10 | ln -s "$(ID_TEMPLATE_HOME)" $(LIBDIR) 11 | else 12 | git clone -q --depth 10 -b main \ 13 | https://github.com/martinthomson/i-d-template $(LIBDIR) 14 | endif 15 | endif 16 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # RTP over QUIC (RoQ) 2 | 3 | This is the working area for the IETF [AVTCORE Working Group](https://datatracker.ietf.org/group/avtcore/documents/) Internet-Draft, "RTP over QUIC (RoQ)". 4 | 5 | * [Editor's Copy](https://ietf-wg-avtcore.github.io/draft-ietf-avtcore-rtp-over-quic/#go.draft-ietf-avtcore-rtp-over-quic.html) 6 | * [Datatracker Page](https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-over-quic) 7 | * [Working Group Draft](https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-rtp-over-quic) 8 | * [Compare Editor's Copy to Working Group Draft](https://ietf-wg-avtcore.github.io/draft-ietf-avtcore-rtp-over-quic/#go.draft-ietf-avtcore-rtp-over-quic.diff) 9 | 10 | 11 | ## Contributing 12 | 13 | See the 14 | [guidelines for contributions](https://github.com/ietf-wg-avtcore/draft-ietf-avtcore-rtp-over-quic/blob/main/CONTRIBUTING.md). 15 | 16 | Contributions can be made by creating pull requests. 17 | The GitHub interface supports creating pull requests using the Edit (✏) button. 18 | 19 | 20 | ## Command Line Usage 21 | 22 | Formatted text and HTML versions of the draft can be built using `make`. 23 | 24 | ```sh 25 | $ make 26 | ``` 27 | 28 | Command line usage requires that you have the necessary software installed. See 29 | [the instructions](https://github.com/martinthomson/i-d-template/blob/main/doc/SETUP.md). 30 | 31 | -------------------------------------------------------------------------------- /draft-ietf-avtcore-rtp-over-quic.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "RTP over QUIC (RoQ)" 3 | docname: draft-ietf-avtcore-rtp-over-quic-latest 4 | category: exp 5 | date: {DATE} 6 | 7 | ipr: trust200902 8 | area: "Web and Internet Transport" 9 | workgroup: "Audio/Video Transport Core Maintenance" 10 | keyword: Internet-Draft 11 | 12 | stand_alone: yes 13 | pi: [toc, sortrefs, symrefs] 14 | submissiontype: IETF 15 | 16 | author: 17 | - 18 | ins: M. Engelbart 19 | name: Mathis Engelbart 20 | organization: Technical University of Munich 21 | email: mathis.engelbart@gmail.com 22 | - 23 | ins: J. Ott 24 | name: Jörg Ott 25 | organization: Technical University of Munich 26 | email: ott@in.tum.de 27 | - 28 | ins: S. Dawkins 29 | name: Spencer Dawkins 30 | organization: Tencent America LLC 31 | email: spencerdawkins.ietf@gmail.com 32 | 33 | informative: 34 | 35 | 3GPP-TS-26.114: 36 | target: https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=1404 37 | title: "IP Multimedia Subsystem (IMS); Multimedia telephony; Media handling and interaction" 38 | date: 2023-01-05 39 | 40 | Copa: 41 | target: https://web.mit.edu/copa/ 42 | title: "Copa: Practical Delay-Based Congestion Control for the Internet" 43 | date: 2018 44 | 45 | IANA-RTCP-PT: 46 | target: https://www.iana.org/assignments/rtp-parameters/rtp-parameters.xhtml#rtp-parameters-4 47 | title: "RTCP Control Packet Types (PT)" 48 | 49 | IANA-RTCP-XR-BT: 50 | target: https://www.iana.org/assignments/rtcp-xr-block-types/rtcp-xr-block-types.xhtml#rtcp-xr-block-types-1 51 | title: "RTCP XR Block Type" 52 | 53 | IANA-RTCP-FMT-RTPFB-PT: 54 | target: https://www.iana.org/assignments/rtp-parameters/rtp-parameters.xhtml#rtp-parameters-8 55 | title: "FMT Values for RTPFB Payload Types" 56 | 57 | IANA-RTCP-FMT-PSFB-PT: 58 | target: https://www.iana.org/assignments/rtp-parameters/rtp-parameters.xhtml#rtp-parameters-9 59 | title: "FMT Values for PSFB Payload Types" 60 | 61 | IANA-RTP-CHE: 62 | target: https://www.iana.org/assignments/rtp-parameters/rtp-parameters.xhtml#rtp-parameters-10 63 | title: "RTP Compact Header Extensions" 64 | 65 | IANA-RTP-SDES-CHE: 66 | target: https://www.iana.org/assignments/rtp-parameters/rtp-parameters.xhtml#sdes-compact-header-extensions 67 | title: "RTP SDES Compact Header Extensions" 68 | 69 | IEEE-1733-2011: 70 | target: https://standards.ieee.org/ieee/1733/4748/ 71 | title: "IEEE 1733-2011 Standard for Layer 3 Transport Protocol for Time-Sensitive Applications in Local Area Networks" 72 | 73 | VJMK88: 74 | target: https://ee.lbl.gov/papers/congavoid.pdf 75 | title: "Congestion Avoidance and Control" 76 | date: November 1988 77 | 78 | RTP-over-QUIC: 79 | target: https://github.com/mengelbart/rtp-over-quic 80 | title: RTP over QUIC 81 | 82 | RoQ-Mininet: 83 | target: https://github.com/mengelbart/rtp-over-quic-mininet 84 | title: Congestion Control for RTP over QUIC Simulations 85 | 86 | roq: 87 | target: https://github.com/mengelbart/roq 88 | title: RTP over QUIC (RoQ) 89 | 90 | gst-roq: 91 | target: https://github.com/bbc/gst-roq 92 | title: RTP-over-QUIC elements for GStreamer 93 | 94 | quic-go: 95 | target: https://github.com/quic-go/quic-go 96 | title: A QUIC implementation in pure Go 97 | 98 | imquic: 99 | target: https://github.com/meetecho/imquic 100 | title: imquic 101 | 102 | gst-plugin-quinn: 103 | target: https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/tree/main/net/quinn 104 | title: gst-plugin-quinn 105 | 106 | --- abstract 107 | 108 | This document specifies a minimal mapping for encapsulating Real-time Transport 109 | Protocol (RTP) and RTP Control Protocol (RTCP) packets within the QUIC protocol. 110 | This mapping is called RTP over QUIC (RoQ). 111 | 112 | This document also discusses how to leverage state that is already available 113 | from the QUIC implementation in the endpoints, in order to reduce the need to 114 | exchange RTCP packets, and describes different options for implementing congestion control and rate 115 | adaptation for RTP without relying on RTCP feedback. 116 | 117 | --- middle 118 | 119 | # Introduction 120 | 121 | This document specifies a minimal mapping for encapsulating Real-time Transport 122 | Protocol (RTP) {{!RFC3550}} and RTP Control Protocol (RTCP) {{!RFC3550}} packets 123 | within the QUIC protocol ({{!RFC9000}}). 124 | This mapping is called RTP over QUIC (RoQ). 125 | 126 | This document also discusses how to leverage state that is already available 127 | from the QUIC implementation in the endpoints, in order to reduce the need to 128 | exchange RTCP packets, and describes different options for implementing congestion control and rate 129 | adaptation for RTP without relying on RTCP feedback. 130 | 131 | ## Background {#background} 132 | 133 | The Real-time Transport Protocol (RTP) {{!RFC3550}} is generally used to carry 134 | real-time media for conversational media sessions, such as video conferences, 135 | across the Internet. Since RTP requires real-time delivery and is tolerant to 136 | packet losses, the default underlying transport protocol has historically been 137 | UDP {{?RFC0768}}, but a large variety of other underlying transport protocols 138 | have been defined for various reasons (e.g., securing media exchange, or 139 | providing a fallback when UDP is blocked along a network path). This document 140 | describes RTP over QUIC, providing one more underlying transport protocol. The 141 | reasons for using QUIC as an underlying transport protocol are given in 142 | {{motivations}}. 143 | 144 | This document describes an application usage of QUIC ({{?RFC9308}}). 145 | As a baseline, the document does not expect more than a standard QUIC implementation 146 | as defined in {{!RFC8999}}, {{!RFC9000}}, {{!RFC9001}}, and {{!RFC9002}}, 147 | providing a secure end-to-end transport. 148 | Beyond this baseline, real-time applications can benefit from QUIC extensions such as unreliable DATAGRAMs 149 | {{!RFC9221}}, which provides additional desirable properties for 150 | real-time traffic (e.g., no unnecessary retransmissions, avoiding head-of-line 151 | blocking). 152 | 153 | ## What's in Scope for this Document {#in-scope} 154 | 155 | This document focuses on providing a secure encapsulation of RTP and RTCP packets 156 | for transmission over QUIC. The expected usage is wherever RTP is used to carry 157 | media packets, allowing QUIC in place of other underlying transport protocols. 158 | We expect RoQ to be used in contexts where a signaling protocol is used to announce or negotiate a media 159 | encapsulation for RTP and the associated transport parameters (such as IP address, port 160 | number). RoQ does not provide a stand-alone media transport capability, because at a minimum, media 161 | transport parameters would need to be statically configured. 162 | 163 | RoQ can be used in many of the point-to-point and multi-endpoint RTP topologies described in {{!RFC7667}}, and can be used with both decentralized and centralized control topologies. 164 | When RoQ is used in a decentralized topology, RTP packets are exchanged directly between ultimate RTP endpoints. 165 | When RoQ is used in a centralized topology, RTP packets transit one or more middleboxes which might function as mixers or translators between ultimate RTP endpoints. 166 | RoQ can also be used in RTP client-server-style settings, e.g., when talking to a 167 | conference server as described in RFC 7667 ({{!RFC7667}}), or, if RoQ 168 | is used to replace RTSP ({{?RFC7826}}), to a media server. 169 | 170 | Moreover, this document describes how a QUIC implementation and its API can be 171 | extended to improve efficiency of the RoQ protocol operation. 172 | 173 | RoQ does not limit the usage of RTP Audio Video Profiles (AVP) 174 | ({{!RFC3551}}), or any RTP-based mechanisms, although it might render some of 175 | them unnecessary, e.g., Secure Real-Time Transport Protocol (SRTP) 176 | ({{?RFC3711}}) might not be needed, because end-to-end security is already 177 | provided by QUIC, and double encryption by QUIC and by SRTP might have more 178 | costs than benefits. Nor does RoQ limit the use of RTCP-based 179 | mechanisms, although some information or functions provided by using RTCP 180 | mechanisms might also be available from the underlying QUIC implementation. 181 | 182 | RoQ supports multiplexing multiple 183 | RTP-based media streams within a single QUIC connection and thus using a single 184 | (destination IP address, destination port number, source IP address, source port 185 | number, protocol) 5-tuple. We note that multiple independent QUIC connections 186 | can be established in parallel using the same 5-tuple., e.g. to carry different media channels. These connections would be 187 | logically independent of one another. 188 | 189 | ## What's Out of Scope for this Document {#out-of-scope} 190 | 191 | This document does not enhance QUIC for real-time media or define a 192 | replacement for, or evolution of, RTP. Work to map other media transport 193 | protocols to QUIC is under way elsewhere in the IETF. 194 | 195 | This document does not specify RoQ for point-to-multipoint applications, because QUIC 196 | itself is not defined for multicast operation. The scope of this document is 197 | limited to unicast RTP, even though nothing would prevent its use 198 | in multicast setups if future QUIC extensions support multicast. 199 | 200 | RoQ does not define new congestion control and rate adaptation algorithms 201 | for use with RTP media, and does not specify the use of particular congestion control and rate adaptation algorithms for use with RTP media. However, {{congestion-control}} discusses multiple ways that congestion control and rate adaptation could be performed at the QUIC and/or at 202 | the RTP layer, and {{api-considerations}} describes information available at the QUIC layer that could be exposed 203 | via an API for the benefit of RTP layer implementation. 204 | 205 | RoQ does not define prioritization mechanisms when handling different 206 | media as those would be dependent on the media themselves and their 207 | relationships. Prioritization is left to the application using RoQ. 208 | 209 | This document does not cover signaling for session setup. SDP for RoQ 210 | is defined in separate documents such as 211 | {{?I-D.draft-dawkins-avtcore-sdp-rtp-quic}}, and can be carried in any signaling 212 | protocol that can carry SDP, including the Session Initiation Protocol (SIP) 213 | ({{?RFC3261}}), Real-Time Protocols for Browser-Based Applications (RTCWeb) 214 | ({{?RFC8825}}), or WebRTC-HTTP Ingestion Protocol (WHIP) 215 | ({{?I-D.draft-ietf-wish-whip}}). 216 | 217 | # Terminology and Notation 218 | 219 | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 220 | "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this 221 | document are to be interpreted as described in BCP 14 {{!RFC2119}} {{!RFC8174}} 222 | when, and only when, they appear in all capitals, as shown here. 223 | 224 | > **Note to the Reader:** {{!RFC3550}} actually describes two closely-related protocols - the RTP Data Transfer Protocol {{Section 5 of !RFC3550}}, and the RTP Control Protocol {{Section 6 of !RFC3550}}. In this document, the term "RTP" refers to the combination of RTP Data Transfer Protocol and RTP Control Protocol, because the distinction isn't relevant for encapsulation, and the term "RTCP" always refers to the RTP Control Protocol. 225 | 226 | > **Note to the Reader:** the meaning of the terms "congestion avoidance", "congestion control" and "rate adaptation" in the IETF community have evolved over the decades since "slow start" and "congestion avoidance" were added as mandatory to implement in TCP, in {{Section 4.2.2.15 of ?RFC1122}}. Historically, "congestion control" usually referred to "achieving network stability" ({{VJMK88}}), by protecting the network from senders who continue to transmit packets that exceed the ability of the network to carry them, even after packet loss occurs (called "congestion collapse"). 227 | 228 | > Modern general-purpose "congestion control" algorithms have moved beyond avoiding congestion collapse, and work to avoid "bufferbloat", which causes increasing round-trip delays, as described in {{rate-adaptation-application-layer}}. 229 | 230 | > "Rate adaptation" more commonly refers to strategies intended to guide senders on when to send "the next packet", so that one-way delays along the network path remain minimal. 231 | 232 | > When RTP runs over QUIC, as described in this document, QUIC is performing congestion control, and the RTP application is responsible for performing rate adaptation. 233 | 234 | > In this document, these terms are used with the meanings listed below, with the recognition that not all the references in this document use these terms in the same way. 235 | 236 | The following terms are used in this document: 237 | 238 | Bandwidth Estimation: 239 | : An algorithm to estimate the available bandwidth of a link in a network. Such 240 | an estimation can be used for rate adaptation, i.e., adapt the rate at which an 241 | application transmits data. 242 | 243 | Congestion Control: 244 | : A mechanism to limit the aggregate amount of data that has been sent over a path to a receiver but has not been acknowledged by the receiver. 245 | This prevents a sender from overwhelming the capacity of a path between a sender and a receiver, which might cause intermediaries on the path to drop packets before they arrive at the receiver. 246 | 247 | Datagram: 248 | : The term "datagram" is ambiguous. Without a qualifier, "datagram" could refer to a UDP packet, or a QUIC DATAGRAM frame, as defined in QUIC's unreliable DATAGRAM extension {{!RFC9221}}, or an RTP packet encapsulated in UDP, or an RTP packet capsulated in QUIC DATAGRAM frame. This document uses the uppercase "DATAGRAM" to refer to a QUIC DATAGRAM frame and the term RoQ datagram as a short form of "RTP packet encapsulated in a QUIC DATAGRAM frame". 249 | 250 | If not explicitly qualified, the term "datagram" in this document refers to an RTP packet, and the uppercase "DATAGRAM" refers to a QUIC DATAGRAM frame. This document also uses the term "RoQ datagram" as a short form of "RTP packet encapsulated in a QUIC DATAGRAM frame". 251 | 252 | Endpoint: 253 | : A QUIC client or QUIC server that participates in an RoQ session. "A RoQ endpoint" is used in this document where that seems clearer than "an endpoint" without qualification. 254 | 255 | Early data: 256 | : Application data carried in a QUIC 0-RTT packet payload, as defined in {{!RFC9000}}. In this document, the early data would be an RTP packet. 257 | 258 | Frame: 259 | : A QUIC frame as defined in {{!RFC9000}}. 260 | 261 | Packet: 262 | : The term "packet" is ambiguous. Without a qualifier, "packet" could refer to a UDP packet, or a QUIC packet, or an RTP/RTCP packet encapsulated in QUIC, or a media packet encapsulated in RTP. If not explicitly qualified, the term "packet" in this document refers to a QUIC packet. 263 | 264 | Peer: 265 | : The term "peer" is ambiguous, and without a qualifier could be understood to refer to an RTP endpoint, a RoQ endpoint, or a QUIC endpoint. In this document, a "peer" is "the other RoQ endpoint that a RoQ endpoint is communicating with", and does not have anything to do with "peer-to-peer" operation versus "client-server" operation. 266 | 267 | Rate Adaptation: 268 | : An application-level mechanism that adjusts the sending rate of an application in response to changing path conditions. For example, an application sending video might respond to indications of congestion by adjusting the resolution of the video it is sending. 269 | 270 | Receiver: 271 | : An endpoint that receives media in RTP packets and might send or receive RTCP packets. 272 | 273 | Sender: 274 | : An endpoint that sends media in RTP packets and might send or receive RTCP packets. 275 | 276 | Stream: 277 | : The term "stream" is ambiguous. Without a qualifier, "stream" could refer to a QUIC stream, as defined in {{!RFC9000}}, a series of media samples, or a series of RTP packets. If not explicitly qualified, the term "stream" in this document refers to a QUIC stream and the term "STREAM" refers to a single QUIC STREAM frame. This document also uses the term "RTP stream" or "RTCP streams" as a short form of "a series of RTP packets" or "a series of RTCP packets", the term "RoQ stream" as a short form of "one or more RTP packets encapsulated in QUIC streams" and the term "media stream" as a short form of "a series of one or more media samples". 278 | 279 | Packet diagrams in this document use the format defined in {{Section 1.3 of RFC9000}} to 280 | illustrate the order and size of fields. 281 | 282 | # Protocol Overview 283 | 284 | This document introduces a mapping of the Real-time Transport Protocol (RTP) to 285 | the QUIC transport protocol. RoQ allows the use of both QUIC streams and 286 | QUIC DATAGRAMs to transport real-time data, and thus, if RTP packets 287 | are to be sent over QUIC DATAGRAMs, the QUIC 288 | implementation MUST support QUIC's DATAGRAM extension. 289 | 290 | {{!RFC3550}} specifies that RTP sessions need to be transmitted on different transport addresses to allow multiplexing between them. 291 | RoQ uses a different approach to leverage the advantages of QUIC connections without managing a separate QUIC connection per RTP session. 292 | {{!RFC9221}} does not provide demultiplexing between different flows on DATAGRAMs but suggests that an application implement a demultiplexing mechanism if required. 293 | An example of such a mechanism would be flow identifiers prepended to each DATAGRAM frame as described in {{Section 2.1 of ?I-D.draft-ietf-masque-h3-datagram}}. 294 | RoQ uses a flow identifier to replace the network address and port number to multiplex many RTP sessions over the same QUIC connection. 295 | 296 | An RTP application is responsible for determining what to send in an encoded media stream, and how to send that encoded media stream within a targeted bitrate. 297 | 298 | This document does not mandate how an application determines what to send in an encoded media stream, because decisions about what to send within a targeted bitrate, and how to adapt to changes in the targeted bitrate, can depend on the application and on the codec in use. For example, adjusting quantization in response to changing network conditions might work well in many cases, but if what's being shared is video that includes text, maintaining readability is important. 299 | 300 | As of this writing, the IETF has produced two Experimental-track congestion control documents for real-time media, Network-Assisted Dynamic Adaptation (NADA) {{!RFC8698}} and Self-Clocked Rate Adaptation for Multimedia (SCReAM) {{!RFC8298}}. 301 | These congestion control algorithms use feedback about the network's performance to calculate target bitrates. When these algorithms are used with RTP, the necessary feedback is generated at the receiver and sent back to the sender via RTCP. 302 | 303 | Since QUIC itself collects some metrics about the network's performance, these QUIC 304 | metrics can be used to generate the required feedback at the sender-side and 305 | provide it to the congestion control algorithm to avoid the additional overhead of the 306 | RTCP stream. This is discussed in more detail in {{rtcp-mapping}}. 307 | 308 | ## Motivation {#motivations} 309 | 310 | From time to time, someone asks the reasonable question, "why would anyone implement and deploy RoQ"? This reasonable question deserves a better answer than "because we can". Upon reflection, the following motivations seem useful to state. 311 | 312 | The motivations in this section are in no particular order, and this reflects the reality that not all implementers and deployers would agree on "the most important motivations". 313 | 314 | ### "Always-On" Transport-level Authentication and Encryption {#alwas-on} 315 | 316 | Although application-level mechanisms to encrypt RTP payloads have existed since the introduction of the Secure Real-time Transport Protocol (SRTP) {{?RFC3711}}, the additional encryption of RTP header fields and contributing sources has only been defined recently (in Cryptex {{?RFC9335}}), and both SRTP and Cryptex are optional capabilities for RTP. 317 | 318 | This is in sharp contrast to "always-on" transport-level encryption in the QUIC protocol, using Transport Layer Security (TLS 1.3) as described in {{?RFC9001}}. QUIC implementations always authenticate the entirety of each packet, and encrypt as much of each packet as is practical, even switching from "long headers", which expose the QUIC header fields needed to establish a connection, to "short headers", which only expose the absolute minimum QUIC header fields needed to identify an existing connection to the receiver, so that the QUIC payload is presented to the correct QUIC application {{?RFC8999}}. 319 | 320 | ### "Always-On" Internet-Safe Congestion Control 321 | 322 | When RTP is carried directly over UDP, as is commonly done, the underlying UDP protocol provides multiplexing using UDP ports, but no transport services beyond multiplexing are provided to the application. All congestion control behavior is up to the RTP application itself, and if anything goes wrong with the application and this condition results in an RTP sender failing to recognize that it is contributing to path congestion, the "worst case" response is to invoke the RTP "circuit breaker" procedures {{?RFC8083}}. These procedures result in "ceasing transmission", as described in {{Section 4.5 of ?RFC8083}}. Because RTCP-based circuit breakers only detect long-lived congestion, a response based on these mechanisms will not happen quickly. 323 | 324 | In contrast, when RTP is carried over QUIC, QUIC implementations maintain their own estimates of key transport parameters needed to detect and respond to possible congestion, and these estimates are independent of any measurements RTP senders and receivers are maintaining. The result is that even if an RTP sender attempts to "send" in the presence of persistent path congestion, QUIC congestion control procedures (for example, the procedures defined in {{?RFC9002}}) will cause the RTP packets to be buffered while QUIC responds to detected packet loss. This happens without RTP senders taking any action, but the RTP sender has no control over this QUIC mechanism. 325 | 326 | Moreover, when a single QUIC connection is used to multiplex both RTP and non-RTP packets as described in {{single-path}}, the shared QUIC connection will still be Internet-safe, with no coordination required. 327 | 328 | While QUIC's response to congestion ensures that RoQ will be "Internet-safe", from the network's perspective, it is helpful to remember that a QUIC sender responds to detected congestion by delaying packets that are already available to send, to give the path to the QUIC receiver time to recover from congestion. 329 | 330 | * If the QUIC connection encapsulates RTP, this means that some RTP packets will be delayed, arriving at the receiver later than a consumer of the RTP flow might prefer. 331 | * If the QUIC connection also encapsulates RTCP, this means that these RTCP messages will also be delayed, and will not be sent in a timely manner. This delay will impact RTT measurements using RTCP and can interfere with a sender's ability to stabilize rate control and achieve audio/video synchronization. 332 | 333 | In summary, 334 | 335 | * Timely RTP stream-level rate adaptation will give a better user experience by minimizing endpoint queuing delays and packet loss, but 336 | * in the presence of packet loss, QUIC connection-level congestion control will respond more quickly and possibly more smoothly to the end of congestion than RTP "circuit breakers". 337 | 338 | ### RTP Rate Adaptation Based on QUIC Feedback {#ra-quic-feedback} 339 | 340 | When RTP is carried directly over UDP, RTP makes use of a large number of RTP-specific feedback mechanisms because there is no other way to receive feedback. 341 | Some of these mechanisms are specific to the type of media RTP is sending, but others can be mapped from underlying QUIC implementations that are using this feedback to perform congestion control for any QUIC connection, regardless of the application reflected in the payload. 342 | This is described in (much) more detail in {{congestion-control}} on rate adaptation, and in {{rtcp-mapping}} on replacing RTCP and RTP header extensions with QUIC feedback. 343 | 344 | One word of caution is in order - RTP implementations might rely on at least some minimal periodic RTCP feedback, in order to determine that an RTP flow is still active, and is not causing sustained congestion (as described in {{?RFC8083}}. 345 | Because the necessary "periodicity" is measured in seconds, the impact of this "duplicate" feedback on path bandwidth utilization is likely close to zero. 346 | 347 | ### Path MTU Discovery and RTP Media Coalescence {#mtu-coal} 348 | 349 | The minimum Path MTU (Maximum Transmission Unit) supported by conformant QUIC implementations is 1200 bytes {{?RFC9000}}. In addition, QUIC implementations allow senders to use either DPLPMTUD ({{?RFC8899}}) or PMTUD ({{?RFC1191}}, {{?RFC8201}}) to determine the actual Path MTU size that the receiver can accept, and that the path between sender and receiver can support. The actual Path MTU can be larger than the Minimum Path MTU. 350 | 351 | This is especially useful in certain conferencing topologies, where otherwise senders would have no choice but to use the lowest Path MTU for all conference participants. Even in point-to-point RTP sessions, this also allows senders to piggyback audio media in the same UDP packet as video media, for example, and also allows QUIC receivers to piggyback QUIC ACK frames on any QUIC packets being transmitted in the other direction. 352 | 353 | ### Multiplexing RTP, RTCP, and Non-RTP Flows on a Single QUIC Connection {#single-path} 354 | 355 | This document defines a flow identifier for multiplexing multiple RTP and 356 | RTCP ports on the same QUIC connection to conserve ports, especially at NATs and 357 | firewalls. {{multiplexing}} describes the multiplexing in more detail. Future 358 | extensions could further build on the flow identifier to multiplex RTP with 359 | other protocols on the same connection, as long as these protocols can co-exist 360 | with RTP without interfering with the ability of this connection to carry 361 | real-time media. 362 | 363 | ### Exploiting Multiple Paths {#multiple-paths} 364 | 365 | Although there is much interest in multiplexing flows on a single QUIC connection as described in {{single-path}}, QUIC also provides the capability of establishing and validating multiple paths for a single QUIC connection as described in {{Section 9 of ?RFC9000}}. Once multiple paths have been validated, a sender can migrate from one path to another with no additional signaling, allowing an endpoint to move from one endpoint address to another without interruption, as long as only a single path is in active use at any point in time. 366 | 367 | Connection migration could be desirable for a number of reasons, but to give one example, this allows a QUIC connection to survive address changes due to a middlebox allocating a new outgoing port, or even a new outgoing IP address. 368 | 369 | The Multipath Extension for QUIC {{?I-D.draft-ietf-quic-multipath}} would allow the application to actively use two or more paths simultaneously, but in all other respects, this functionality is the same as QUIC connection migration. 370 | 371 | A sender can use these capabilities to more effectively exploit multiple paths between sender and receiver with no action required from the application, even if these paths have different path characteristics. Examples of these different path characteristics include senders handling paths differently if one path has higher available bandwidth and the other has lower one-way latency, or if one is a more costly cellular path and the other is a less costly WiFi path. 372 | 373 | Some of these differences can be detected by QUIC itself, while other differences must be described to QUIC based on policy, etc. Possible RTP implementation strategies for path selection and utilization are not discussed in this document. Path scheduling APIs to let applications control these mechanisms are a topic for future research and might need further specification in future documents. 374 | 375 | ### Exploiting New QUIC Capabilities {#new-quic} 376 | 377 | The first version of the QUIC protocol described in {{!RFC9000}} has been completed, but extensions to QUIC are still under active development in the IETF. Because of this, using QUIC as a transport for a mature protocol like RTP allows developers to exploit new transport capabilities as they become available. 378 | 379 | ## RTP with QUIC Streams, QUIC DATAGRAMs, and a Mixture of Both {#streams-and-datagrams} 380 | 381 | This document describes the use of QUIC streams and DATAGRAMs as RTP encapsulations but does not take a position on which encapsulation an application ought to use. Indeed, an application can use both QUIC streams and DATAGRAM encapsulations on the same QUIC connection. The choice of encapsulation is left to the application developer, but it is worth noting differences that are relevant when making this choice. 382 | 383 | QUIC {{!RFC9000}} was initially designed to carry HTTP {{?RFC9114}} in QUIC streams, and QUIC streams provide what HTTP application developers need - for example, a stateful, connection-oriented, flow-controlled, reliable, ordered stream of bytes to an application. QUIC streams can be multiplexed over a single QUIC connection, using stream IDs to demultiplex incoming messages. 384 | 385 | QUIC DATAGRAMs {{!RFC9221}} were developed as a QUIC extension, intended to support applications that do not need reliable delivery of application data. This extension defines two DATAGRAM frame types (one including a length field, the other not including a length field), and these DATAGRAM frames can co-exist with QUIC streams within a single QUIC connection, sharing the connection's cryptographic and authentication context, and congestion controller context. 386 | 387 | There is no default relative priority between DATAGRAM frames with respect to each other, and there is no default priority between DATAGRAM frames and QUIC STREAM frames. QUIC implementations can present an API to allow applications to assign relative priorities within a QUIC connection, but this is not mandated by the standard and might not be present in all implementations. 388 | 389 | Because DATAGRAMs are an extension to QUIC, they inherit a great deal of functionality from QUIC (much of which is described in {{motivations}}); so much so that it is easier to explain what DATAGRAMs do NOT inherit. 390 | 391 | * DATAGRAM frames do not provide any explicit flow control signaling. This means that a QUIC receiver might not be able to commit the necessary resources to process incoming frames, but the purpose for DATAGRAM frames is to carry application-level information that can be lost and will not be retransmitted. 392 | * DATAGRAM frames cannot be fragmented. They are limited in size by the max_datagram_frame_size transport parameter, and further limited by the max_udp_payload_size transport parameter and the Path MTU between endpoints. 393 | * DATAGRAM frames belong to a QUIC connection as a whole. There is no QUIC-level way to multiplex/demultiplex DATAGRAM frames within a single QUIC connection. Any multiplexing identifiers must be added, interpreted, and removed by an application, and they will be sent as part of the payload of the DATAGRAM frame itself. 394 | 395 | DATAGRAM frames do inherit the QUIC connection's congestion controller. This means that although there is no frame-level flow control, DATAGRAM frames can be delayed until the controller allows them to be sent or dropped (with an optional notification to the sending application). Implementations can also delay sending DATAGRAM frames to maintain consistent packet pacing (as described in {{Section 7.7 of ?RFC9002}}), and can allow an application to specify a sending expiration time, but these capabilities are not mandated by the standard and might not be present in all implementations. 396 | 397 | Because DATAGRAMs are an extension to QUIC, a RoQ endpoint cannot assume that its peer supports this extension. 398 | The RoQ endpoint might discover that its peer does not support DATAGRAMs in one of two ways: 399 | 400 | * as part of the signaling process to set up QUIC connections, or 401 | * during negotiation of the DATAGRAM extension during the QUIC handshake. 402 | 403 | When either of these situations happen, the RoQ endpoint needs to make a decision about what to do next. 404 | 405 | * If the use of DATAGRAMs was critical for the application, the endpoint can simply close the QUIC connection, allowing someone or something to correct this mismatch, so that DATAGRAMs can be used. 406 | * If the use of DATAGRAMs was not critical for the application, the endpoint can negotiate the use of QUIC streams instead. 407 | 408 | ## Supported RTP Topologies {#topologies} 409 | 410 | RoQ supports only some of the RTP topologies described in 411 | {{?RFC7667}}. Most notably, due to QUIC {{!RFC9000}} being a purely IP unicast 412 | protocol at the time of writing, RoQ cannot be used as a transport 413 | protocol for any of the paths that rely on IP multicast in several multicast 414 | topologies (e.g., *Topo-ASM*, *Topo-SSM*, *Topo-SSM-RAMS*). 415 | 416 | Some "multicast topologies" can include IP unicast paths (e.g., *Topo-SSM*, 417 | *Topo-SSM-RAMS*). In these cases, the unicast paths can use RoQ. 418 | 419 | RTP supports different types of translators and mixers. Whenever a middlebox 420 | needs to access the content of QUIC frames (e.g., *Topo-PtP-Translator*, *Topo-PtP-Relay*, *Topo-Trn-Translator*, *Topo-Media-Translator*), 421 | the QUIC connection will be terminated at that middlebox. 422 | 423 | RoQ streams (see {{quic-streams}}) can support much larger RTP 424 | packet sizes than other transport protocols such as UDP can, which can lead to 425 | problems when transport translators which translate from RoQ to RTP 426 | over a different transport protocol. A similar problem can occur if a translator 427 | needs to translate from RTP over UDP to RoQ over DATAGRAMs, where the max_datagram_frame_size 428 | of a QUIC DATAGRAM can be smaller than the MTU of a UDP datagram. In both cases, 429 | the translator might need to rewrite the RTP packets to fit into the smaller MTU 430 | of the other protocol. Such a translator might need codec-specific knowledge to 431 | packetize the payload of the incoming RTP packets in smaller RTP packets. 432 | 433 | Additional details are provided in the following table. 434 | 435 | | RFC 7667 Section | Shortcut Name | RTP over QUIC? | Comments | 436 | | -------- | -------- | -------- | -------- | 437 | | [3.1](https://datatracker.ietf.org/doc/html/rfc7667#section-3.1) | Topo-Point-to-Point | yes | | 438 | | [3.2.1.1](https://datatracker.ietf.org/doc/html/rfc7667#section-3.2.1.1) | Topo-PtP-Relay | yes | Note-NAT | 439 | | [3.2.1.2](https://datatracker.ietf.org/doc/html/rfc7667#section-3.2.1.2) | Topo-Trn-Translator | yes | Note-MTU
Note-SEC | 440 | | [3.2.1.3](https://datatracker.ietf.org/doc/html/rfc7667#section-3.2.1.3) | Topo-Media-Translator | yes | Note-MTU | 441 | | [3.2.2](https://datatracker.ietf.org/doc/html/rfc7667#section-3.2.2) | Topo-Back-To-Back | yes | Note-SEC
Note-MTU
Note-MCast| 442 | | [3.3.1](https://datatracker.ietf.org/doc/html/rfc7667#section-3.3.1) | Topo-ASM | no | Note-MCast | 443 | | [3.3.2](https://datatracker.ietf.org/doc/html/rfc7667#section-3.3.2) | Topo-SSM | partly | Note-MCast
Note-UCast-MCast | 444 | | [3.3.3](https://datatracker.ietf.org/doc/html/rfc7667#section-3.3.3) | Topo-SSM-RAMS | partly | Note-MCast
Note-MCast-UCast | 445 | | [3.4](https://datatracker.ietf.org/doc/html/rfc7667#section-3.4) | Topo-Mesh | yes | Note-MCast | 446 | | [3.5.1](https://datatracker.ietf.org/doc/html/rfc7667#section-3.5.1) | Topo-PtM-Trn-Translator | possibly | Note-MCast
Note-MTU
Note-Topo-PtM-Trn-Translator | 447 | | [3.6](https://datatracker.ietf.org/doc/html/rfc7667#section-3.6) | Topo-Mixer | possibly | Note-MCast
Note-Topo-Mixer| 448 | | [3.6.1](https://datatracker.ietf.org/doc/html/rfc7667#section-3.6.1) | Media-Mixing-Mixer | partly | Note-Topo-Mixer | 449 | | [3.6.2](https://datatracker.ietf.org/doc/html/rfc7667#section-3.6.2) | Media-Switching-Mixer | partly | Note-Topo-Mixer | 450 | | [3.7](https://datatracker.ietf.org/doc/html/rfc7667#section-3.7) | Selective Forwarding Middlebox | yes | Note-MCast
Note-Topo-Mixer | 451 | | [3.8](https://datatracker.ietf.org/doc/html/rfc7667#section-3.8) | Topo-Video-switch-MCU | yes | Note-MTU
Note-MCast
Note-Topo-Mixer | 452 | | [3.9](https://datatracker.ietf.org/doc/html/rfc7667#section-3.9) | Topo-RTCP-terminating-MCU | yes | Note-MTU
Note-MCast
Note-Topo-Mixer | 453 | | [3.10](https://datatracker.ietf.org/doc/html/rfc7667#section-3.10) | Topo-Split-Terminal | yes | Note-MCast| 454 | | [3.11](https://datatracker.ietf.org/doc/html/rfc7667#section-3.11) | Topo-Asymmetric | Possibly | Note-Warn,
Note-MCast,
Note-MTU | 455 | 456 | Note-NAT: 457 | : Not supported, because QUIC {{!RFC9000}} does not support NAT traversal. 458 | 459 | Note-MTU: 460 | : Supported, but might require MTU adaptation. 461 | 462 | Note-Sec: 463 | : Note that because RoQ uses QUIC as its underlying transport, and QUIC authenticates the entirety of each packet and encrypts as much of each packet as is practical, RoQ secures both RTP headers and RTP payloads, while other RTP transports 464 | do not. {{sec-considerations}} describes strategies to prevent the inadvertent 465 | disclosure of RTP sessions to unintended third parties. 466 | 467 | Note-MCast: 468 | : Not supported, because QUIC {{!RFC9000}} does not support IP multicast. 469 | 470 | Note-UCast-MCast: 471 | : The topology refers to a *Distribution Source*, which receives and relays RTP 472 | from a number of different media senders via unicast before relaying it to the 473 | receivers via multicast. QUIC can be used between the senders and the 474 | *Distribution Source*. 475 | 476 | Note-MCast-UCast: 477 | : The topology refers to a *Burst Source* or *Retransmission Source*, which 478 | retransmits RTP to receivers via unicast. QUIC can be used between the 479 | *Retransmission Source* and the receivers. 480 | 481 | Note-Topo-PtM-Trn-Translator: 482 | : Supported for IP unicast paths between RTP sources and translators. 483 | 484 | Note-Topo-Mixer: 485 | : Supported for IP unicast paths between RTP senders and mixers. 486 | 487 | Note-Warn: 488 | : Quote from {{?RFC7667}}: *This topology is so problematic and it is so easy to get the RTCP processing wrong, that it is NOT RECOMMENDED to implement this topology.* 489 | 490 | # Connection Establishment and Application-Layer Protocol Negotiation {#alpn} 491 | 492 | QUIC requires the use of Application-Layer Protocol Negotiation (ALPN) {{!RFC7301}} tokens during connection setup. RoQ 493 | uses "roq" as the ALPN token, included as part of the TLS handshake (see also 494 | {{iana-considerations}}). 495 | 496 | Note that the "roq" ALPN token is not tied to a specific RTP profile, even 497 | though the RTP profile could be considered part of the application usage. This allows 498 | different RTP sessions, which might use different RTP profiles, to be 499 | carried within the same QUIC connection. 500 | 501 | ## Draft version identification 502 | 503 | > **RFC Editor's note:** Please remove this section prior to publication of a 504 | > final version of this document. 505 | 506 | RoQ uses the ALPN token "roq" to identify itself during QUIC connection setup. 507 | 508 | Only implementations of the final, published RFC can identify themselves as 509 | "roq". Until such an RFC exists, implementations MUST NOT identify themselves 510 | using this string. 511 | 512 | Implementations of draft versions of the protocol MUST add the string "-" and 513 | the corresponding draft number to the identifier. For example, 514 | draft-ietf-avtcore-rtp-over-quic-09 is identified using the string "roq-09". 515 | 516 | Non-compatible experiments that are based on these draft versions MUST append 517 | the string "-" and an experiment name to the identifier. 518 | 519 | # Encapsulation {#encapsulation} 520 | 521 | This section describes the encapsulation of RTP packets in QUIC. 522 | 523 | QUIC supports two transport methods: QUIC streams {{!RFC9000}} and DATAGRAMs {{!RFC9221}}. This document specifies mappings of RTP to both transport modes. 524 | Senders MAY combine both modes by sending some RTP packets over the same or different QUIC streams and others in DATAGRAMs. 525 | 526 | {{multiplexing}} introduces a multiplexing mechanism that supports multiplexing multiple RTP sessions and RTCP. {{quic-streams}} and {{quic-datagrams}} explain 527 | the specifics of mapping RTP to QUIC streams and DATAGRAMs, respectively. 528 | 529 | ## Multiplexing {#multiplexing} 530 | 531 | RoQ uses flow identifiers to multiplex different RTP streams on a 532 | single QUIC connection. A flow identifier is a QUIC variable-length integer as 533 | described in {{Section 16 of !RFC9000}}. Each flow identifier is associated with 534 | an RTP stream. 535 | 536 | In a QUIC connection using the ALPN token defined in {{alpn}}, every DATAGRAM and every QUIC stream MUST start with a flow identifier. 537 | An endpoint MUST NOT send any data in a DATAGRAM or stream that is not associated with the flow 538 | identifier which started the DATAGRAM or stream. 539 | 540 | RTP packets of different RTP sessions MUST use distinct flow 541 | identifiers. If endpoints wish to send multiple types of media in a single RTP 542 | session, they can do so by following the guidance specified in {{?RFC8860}}. 543 | 544 | A single RTP session can be associated with one or two flow identifiers. Thus, 545 | it is possible to send RTP and RTCP packets belonging to the same session using 546 | different flow identifiers. RTP and RTCP packets of a single RTP session can use 547 | the same flow identifier (following the procedures defined in {{?RFC5761}}), or 548 | they can use different flow identifiers. 549 | 550 | Endpoints need to associate flow identifiers with RTP streams. Depending on the 551 | context of the application, the association can be statically configured, 552 | signaled using an out-of-band signaling mechanism (e.g., SDP), or applications 553 | might be able to identify the stream based on the RTP packets sent on the stream 554 | (e.g., by inspecting the payload type). 555 | 556 | If an endpoint receives a flow identifier that it cannot associate with an RTP 557 | stream, the endpoint MAY close the connection using the ROQ_UNKNOWN_FLOW_ID 558 | error code. Closing the connection can be a valid response if it is not expected 559 | that out of band signaling is still ongoing and the application cannot handle 560 | unknown flow identifiers. 561 | 562 | If the association of flow identifiers with RTP streams depends on out-of-band 563 | signaling, the signaling mechanism SHOULD be completed before the exchange of 564 | RTP packets using the new flow identifiers starts. 565 | 566 | In cases where it cannot be guaranteed that signaling is completed before RTP 567 | packets are transmitted, streams or DATAGRAMs with a given flow identifer can 568 | arrive before the signaling finished. In that case, an endpoint cannot associate 569 | the stream or DATAGRAM with the corresponding RTP stream. The endpoint can 570 | buffer streams and DATAGRAMs using an unknown flow identifier until they can be 571 | associated with the corresponding RTP stream. To avoid resource exhaustion, the 572 | buffering endpoint MUST limit the number of streams and DATAGRAMs to buffer. If 573 | the number of buffered streams exceeds the limit on buffered streams, the 574 | endpoint MUST send a STOP_SENDING with the error code ROQ_UNKNOWN_FLOW_ID. It is 575 | an implementation's choice on which stream to send STOP_SENDING. If the number 576 | of buffered DATAGRAMs exceeds the limit on buffered DATAGRAMs, the endpoint MUST 577 | drop a DATAGRAM. It is an implementation's choice which DATAGRAMs to drop. 578 | 579 | Flow identifiers introduce some overhead in addition to the header overhead of 580 | RTP and QUIC. QUIC variable-length integers require between one and eight 581 | bytes depending on the number expressed. Thus, using low 582 | numbers as session identifiers first will minimize this additional overhead. 583 | 584 | ## QUIC Streams {#quic-streams} 585 | 586 | To send RTP packets over QUIC streams, a sender MUST open at least one new unidirectional QUIC stream. 587 | RoQ uses unidirectional streams, because there is no synchronous relationship between sent and received RTP packets. 588 | An endpoint that receives a bidirectional stream with a flow identifier that is associated with an RTP stream, MUST stop reading from the stream and send a CONNECTION_CLOSE frame with the frame type set to APPLICATION_ERROR and the error code set to ROQ_STREAM_CREATION_ERROR. 589 | 590 | The underlying QUIC implementation might be acting as either a QUIC client or QUIC server, so the unidirectional QUIC stream can be either client-initiated or server-initiated, as described in {{Section 2.1 of !RFC9000}}, depending on the role. 591 | The QUIC implementation's role is not controlled by RoQ, and can be negotiated using a separate signaling protocol. 592 | 593 | A RoQ sender can open new QUIC streams for different RTP packets using the same flow identifier. This allows RoQ senders to use QUIC streams while avoiding head-of-line blocking. 594 | 595 | Because a sender can continue sending on a stream with a lower stream identifier after starting packet transmission on a stream with a higher stream identifier, a RoQ receiver MUST be prepared to receive RoQ packets on any number of QUIC streams (subject to its limit on parallel open streams) and MUST NOT make assumptions about which RTP sequence numbers are carried in any particular stream. 596 | 597 | ### Stream Encapsulation 598 | 599 | {{fig-stream-payload}} shows the encapsulation format for RoQ Streams. 600 | 601 | ~~~ 602 | Payload { 603 | Flow Identifier (i), 604 | RTP Payload(..) ..., 605 | } 606 | ~~~ 607 | {: #fig-stream-payload title="RoQ Streams Payload Format"} 608 | 609 | Flow Identifier: 610 | 611 | : Flow identifier to demultiplex different data flows on the same QUIC 612 | connection. 613 | 614 | RTP Payload: 615 | 616 | : Contains the RTP payload; see {{fig-rtp-stream-payload}} 617 | 618 | The payload in a QUIC stream starts with the flow identifier followed by one or 619 | more RTP payloads. All RTP payloads sent on a stream MUST belong to 620 | the RTP session with the same flow identifier. 621 | 622 | Each payload begins with a length field indicating the length of the RTP 623 | packet, followed by the RTP packet itself, see {{fig-rtp-stream-payload}}. 624 | 625 | ~~~ 626 | RTP Payload { 627 | Length(i), 628 | RTP Packet(..), 629 | } 630 | ~~~ 631 | {: #fig-rtp-stream-payload title="RTP payload for QUIC streams"} 632 | 633 | Length: 634 | 635 | : A QUIC variable length integer (see {{Section 16 of !RFC9000}}) describing the 636 | length of the following RTP packets in bytes. 637 | 638 | RTP Packet: 639 | 640 | : The RTP packet to transmit. 641 | 642 | ### Media Frame Cancellation 643 | 644 | QUIC uses RESET\_STREAM and STOP\_SENDING frames to terminate the sending part 645 | of a stream and to request termination of an incoming stream by the sending 646 | peer respectively. 647 | 648 | A RoQ receiver that is no longer interested in reading a certain portion of 649 | the media stream can signal this to the sending peer using a STOP\_SENDING 650 | frame. 651 | 652 | If a RoQ sender discovers that an RTP packet is no longer needed and knows that the RTP packet has not yet been successfully and completely transmitted, it can use RESET\_STREAM to tell the RoQ receiver that the RoQ sender is discarding the RTP packet. 653 | 654 | In both cases, the error code of the RESET\_STREAM frame or the STOP\_SENDING 655 | frame MUST be set to ROQ\_FRAME\_CANCELLED. 656 | 657 | STOP\_SENDING is not a request to the sender to stop sending RTP media, only an indication that a RoQ receiver stopped reading the QUIC stream being used to carry that RTP media. 658 | This can mean that the RoQ receiver is no longer able to use the media frames being received because they are "too old". 659 | A sender with additional media frames to send can continue sending them on another QUIC stream. 660 | Alternatively, new media frames can be sent as DATAGRAMs (see {{quic-datagrams}}). 661 | In either case, a RoQ sender resuming operation after receiving STOP_SENDING can continue starting with the newest media frames available for sending. This allows a RoQ receiver to "fast forward" to media frames that are "new enough" to be used. 662 | 663 | Any media frame that has already been sent on the QUIC stream that received the STOP\_SENDING frame, MUST NOT be sent again on the new QUIC stream(s) or DATAGRAMs. 664 | 665 | Note that an RTP receiver cannot request a reset of a particular media 666 | frame because the sending QUIC implementation might already have sent data for 667 | one or more following media frames on the same stream. In that case, STOP\_SENDING and the 668 | resulting RESET\_STREAM would also discard the following media frames and thus lead 669 | to unintentionally skipping one or more media frames. 670 | 671 | A translator that translates between two endpoints, both connected via QUIC, 672 | MUST forward RESET\_STREAM frames received from one end to the other unless it 673 | forwards the RTP packets encapsulated in DATAGRAMs. 674 | 675 | QUIC implementations will fragment large RTP packets into smaller QUIC STREAM 676 | frames. The data carried in these QUIC STREAM frames is transmitted reliably and 677 | is delivered to the receiving application in order, so that a receiving application can read a complete RTP packet from 678 | the stream as long as the stream is not closed with a RESET\_STREAM frame. No 679 | retransmission has to be implemented by the application since data that was 680 | carried in QUIC frames that were lost in transit is retransmitted by QUIC. 681 | 682 | ### Flow control and MAX\_STREAMS {#quic-flow-cc} 683 | 684 | In order to permit QUIC streams to open, a RoQ sender MUST configure non-zero minimum values for the number of permitted streams and the initial stream flow-control window. 685 | These minimum values control the number of parallel, or simultaneously active, RTP flows. 686 | Endpoints that excessively restrict the number of streams or the flow-control window of these streams will increase the chance that the sending peer reaches the limit early and becomes blocked. 687 | 688 | Opening new streams for new packets can implicitly limit the number of packets 689 | concurrently in transit because the QUIC receiver provides an upper bound of 690 | parallel streams, which it can update using QUIC MAX\_STREAMS frames. The number 691 | of packets that can be transmitted concurrently depends on several factors, 692 | such as the number of RTP streams within a QUIC connection, the bitrate of the 693 | media streams, and the maximum acceptable transmission delay of a given packet. 694 | Receivers are responsible for providing senders enough credit to open new 695 | streams for new packets at any time. 696 | 697 | As an example, consider a conference scenario 698 | with 20 participants. Each participant receives audio and video streams of every 699 | other participant from a central RTP middlebox. If the sender opens a new QUIC stream 700 | for every frame at 30 frames per second video and 50 frames per second audio, it 701 | will open 1520 new QUIC streams per second. A receiver must provide at least 702 | that many credits for opening new unidirectional streams to the RTP middlebox every 703 | second. 704 | 705 | In addition, the receiver ought to also consider the requirements of RTCP streams. 706 | These considerations can also be relevant when implementing signaling since it 707 | can be necessary to inform the receiver about how many stream 708 | credits it will have to provide to the sending peer, and how rapidly it must provide these stream credits. 709 | 710 | ## QUIC DATAGRAMs {#quic-datagrams} 711 | 712 | Senders can also transmit RTP packets in QUIC DATAGRAMs, using 713 | a QUIC extension described in {{!RFC9221}}. 714 | DATAGRAMs can only be used if the use of the DATAGRAM extension was successfully negotiated during the QUIC handshake. 715 | If the DATAGRAM extension was negotiated using a signaling protocol, but was not also negotiated during the resulting QUIC handshake, an endpoint can close the connection with the ROQ\_EXPECTATION\_UNMET error code. 716 | 717 | DATAGRAMs preserve application frame boundaries. 718 | Thus, a single RTP packet can be mapped to a single DATAGRAM without additional framing. 719 | Because QUIC DATAGRAMs cannot be IP-fragmented ({{Section 5 of !RFC9221}}), senders need to consider the header overhead associated with DATAGRAMs, and ensure that the RTP packets, including their payloads, flow identifier, QUIC, and IP headers, will fit into the Path MTU. 720 | 721 | {{fig-dgram-payload}} shows the encapsulation format for RoQ 722 | Datagrams. 723 | 724 | ~~~ 725 | Payload { 726 | Flow Identifier (i), 727 | RTP Packet (..), 728 | } 729 | ~~~ 730 | {: #fig-dgram-payload title="RoQ Datagram Payload Format"} 731 | 732 | Flow Identifier: 733 | 734 | : Flow identifier to demultiplex different data flows on the same QUIC 735 | connection. 736 | 737 | RTP Packet: 738 | 739 | : The RTP packet to transmit. 740 | 741 | RoQ senders need to be aware that QUIC uses the concept of QUIC frames, and QUIC connections use 742 | different kinds of QUIC frames to carry different application and control data types. 743 | A single QUIC packet can contain more than one QUIC frame, including, for example, QUIC STREAM frames or DATAGRAM frames carrying application data and ACK frames carrying QUIC acknowledgments, as long as the overall size fits into the MTU. 744 | One implication is that the number of packets a QUIC stack transmits depends on whether it can fit ACK and DATAGRAM frames in the same QUIC packet. 745 | Suppose the application creates many DATAGRAM frames that fill up the QUIC packet. 746 | In that case, the QUIC stack would need to create additional packets for ACK frames, and possibly other control frames. 747 | The additional overhead could, in some cases, be reduced if the application creates smaller RTP packets, such that the resulting DATAGRAM frame can fit into a QUIC packet that can also carry ACK frames. Another implication is that multiple RTP packets in either QUIC streams or QUIC DATAGRAMs might be encapsulated in a single QUIC packet, which is discussed in more detail in {{coalescing-packets}}. 748 | 749 | Since DATAGRAMs are not retransmitted on loss (see also 750 | {{transport-layer-feedback}} for loss signaling), if an application is using DATAGRAMs and wishes to 751 | retransmit lost RTP packets, the application has to carry out that retransmission. 752 | RTP retransmissions can be done in the same RTP session or in a 753 | different RTP session {{!RFC4588}} and the flow identifier MUST be set to the 754 | flow identifier of the RTP session in which the retransmission happens. 755 | 756 | ## Encapsulation Considerations for RTCP 757 | 758 | The same encapsulation as described above for RTP packets can also be used to carry RTCP packets back from the receiver to the sender. Both RTP and RTCP can be transported in either QUIC DATAGRAM frames or QUIC STREAM frames. 759 | If a receiver sends aggregated RTCP reports for multiple RTP streams, the flow identifier no longer matches the flow identifier for a single RTP stream. Thus the sender always needs to inspect the received RTCP packet independent of the flow identifier used to the RTCP flow to determine to which of the RTP flows the received packets apply. 760 | This is also the reason why bidirectional streams are not allowed, as the received RTCP packets would not necessarily apply to the same RTP stream being sent on the same flow. 761 | In addition, allowing a bidirectional stream could result in a situation where the sender has closed its side of the QUIC stream, but the receiver continues to send RTCP in the opposite direction. 762 | Thus it makes more sense if the sender and receiver agree on one or multiple unidirectional streams to transport any RTCP messages. 763 | 764 | # Connection Shutdown 765 | 766 | Either endpoint can close the connection for any of a variety of reasons. If one of the 767 | endpoints wants to close the RoQ connection, the endpoint can use a QUIC 768 | CONNECTION\_CLOSE frame with one of the error codes defined in 769 | {{error-handling}}. 770 | 771 | # Error Handling {#error-handling} 772 | 773 | The following error codes are defined for use when abruptly terminating RoQ streams, 774 | aborting reading of RoQ streams, or immediately closing RoQ connections. 775 | 776 | ROQ\_NO\_ERROR (0x00): 777 | : No error. This is used when the connection or stream needs to be closed, but 778 | there is no error to signal. 779 | 780 | ROQ\_GENERAL\_ERROR (0x01): 781 | : An error that does not match a more specific error code occurred. 782 | 783 | ROQ\_INTERNAL\_ERROR (0x02): 784 | : An internal error has occurred in the RoQ stack. 785 | 786 | ROQ\_PACKET\_ERROR (0x03): 787 | : Invalid payload format, e.g., length does not match RTP packet, invalid flow id 788 | encoding, non-RTP on RTP-flow ID, etc. 789 | 790 | ROQ\_STREAM\_CREATION\_ERROR (0x04): 791 | : The endpoint detected that its peer created a stream that violates the ROQ protocol, e.g., a bidirectional stream, for sending RTP packets. 792 | 793 | ROQ\_FRAME\_CANCELLED (0x05): 794 | : A receiving endpoint is using STOP_SENDING on the current stream to request 795 | new frames be sent on new streams. Similarly, a sender notifies a receiver that 796 | retransmissions of a frame were stopped using RESET\_STREAM and new frames will 797 | be sent on new streams. 798 | 799 | ROQ\_UNKNOWN\_FLOW\_ID (0x06): 800 | : An endpoint was unable to handle a flow identifier, e.g., because it was not 801 | signaled or because the endpoint does not support multiplexing using arbitrary 802 | flow identifiers. 803 | 804 | ROQ\_EXPECTATION\_UNMET (0x07): 805 | : RoQ out-of-band signaling set expectations for QUIC transport, but the resulting QUIC connection would not meet those expectations. 806 | 807 | # Congestion Control and Rate Adaptation {#congestion-control} 808 | 809 | Like any other application on the Internet, RoQ applications need a mechanism to 810 | perform congestion control to avoid overloading the network. QUIC is a 811 | congestion-controlled transport protocol. RTP does not mandate a single 812 | congestion control mechanism. RTP suggests that the RTP profile defines 813 | congestion control according to the expected properties of the application's 814 | environment. 815 | 816 | This document discusses aspects of transport level congestion control in 817 | {{cc-quic-layer}} and application layer rate control in 818 | {{rate-adaptation-application-layer}}. It does not mandate any specific 819 | congestion control algorithm for QUIC or rate adaptation algorithm for RTP. 820 | 821 | This document also gives guidance about avoiding problems with *nested* 822 | congestion controllers in {{rate-adaptation-application-layer}}. 823 | 824 | This document also discusses congestion control implications of using shared or 825 | multiple separate QUIC connections to send and receive multiple independent 826 | RTP streams in {{shared-connections}}. 827 | 828 | ## Congestion Control at the Transport Layer {#cc-quic-layer} 829 | 830 | QUIC is a congestion-controlled transport protocol. Senders are required to 831 | employ some form of congestion control. The default congestion control specified 832 | for QUIC in {{!RFC9002}} is similar to TCP NewReno {{?RFC6582}}, but senders are 833 | free to choose any congestion control algorithm as long as they follow the 834 | guidelines specified in {{Section 3 of ?RFC8085}}, and QUIC implementors make 835 | use of this freedom. 836 | 837 | Congestion control mechanisms are often implemented at the transport layer of the protocol stack, but can also be implemented at the application layer. 838 | 839 | A congestion control mechanism could respond to actual packet loss (detected by timeouts), or to impending packet loss (signaled by mechanisms such as Explicit Congestion Notification {{?RFC3168}}). 840 | 841 | For real-time traffic, it is best that the QUIC implementation uses a congestion 842 | controller that aims at keeping queues at intermediary 843 | network elements, and thus latency, as short as possible. Delay-based congestion control algorithms 844 | might use, for example, an increasing one-way delay as a signal of impending 845 | congestion, and adjust the sending rate to prevent continued increases in 846 | one-way delay. 847 | 848 | A wide variety of congestion control algorithms for real-time media have been developed (for example, "Google Congestion Controller" {{?I-D.draft-ietf-rmcat-gcc}}). 849 | The IETF has defined two such algorithms in Experimental RFCs (SCReAM {{?RFC8298}} and NADA {{?RFC8698}}). 850 | These algorithms 851 | for RTP are specifically tailored for real-time transmission at low latencies, 852 | but the guidance in this section would apply to any congestion control algorithm that meets the 853 | requirements described in "Congestion Control Requirements for Interactive 854 | Real-Time Media" {{!RFC8836}}. 855 | 856 | Some low latency congestion control algorithms depend on detailed arrival time feedback to estimate the current one-way delay between sender and receiver, which is unavailable in QUIC {{!RFC9000}} without extensions. 857 | QUIC implementations can use an extension to add this information to QUIC as described in {{optional-extensions}}. 858 | In addition to these dedicated real-time media congestion-control algorithms, QUIC implementations could support the Low Latency, Low Loss, and Scalable Throughput (L4S) Internet Service {{?RFC9330}}, which limits growth in round-trip delays that result from increasing queuing delays. 859 | While L4S does not rely on a QUIC protocol extension, L4S does rely on support from network devices along the path from sender to receiver. 860 | 861 | The application needs a mechanism to query the available bandwidth to adapt 862 | media codec configurations. If the employed congestion controller of the QUIC 863 | connection keeps an estimate of the available bandwidth, it could also expose an API 864 | to the application to query the current estimate. If the congestion controller 865 | cannot provide a current bandwidth estimate to the application, the sender can 866 | implement an alternative bandwidth estimation at the application layer as 867 | described in {{rate-adaptation-application-layer}}. 868 | 869 | It is assumed that the congestion controller in use provides a pacing mechanism 870 | to determine when a packet can be sent to avoid bursts and minimize variation in 871 | inter-packet arrival times. The currently proposed congestion control algorithms 872 | for real-time communications (e.g., SCReAM and NADA) provide such pacing 873 | mechanisms, and the QUIC exemplary congestion control algorithm ({{Section 7.7 874 | of !RFC9002}}) recommends pacing for senders. 875 | 876 | ## Rate Adaptation at the Application Layer {#rate-adaptation-application-layer} 877 | 878 | RTP itself does not specify a congestion control algorithm, but {{!RFC8888}} 879 | defines an RTCP feedback message intended to enable rate adaptation for 880 | interactive real-time traffic using RTP, and successful rate adaptation will 881 | accomplish congestion control as well. 882 | 883 | If an application cannot access a bandwidth estimation from the QUIC layer, the 884 | application can alternatively implement a bandwidth estimation algorithm at the 885 | application layer. Congestion control algorithms for real-time media such as GCC 886 | {{?I-D.draft-ietf-rmcat-gcc}}, NADA {{?RFC8698}}, and SCReAM {{?RFC8298}} expose 887 | a target bitrate to dynamically reconfigure media codecs to produce media at 888 | the rate of the observed available bandwidth. Applications can use the same 889 | bandwidth estimation to adapt their rate when using QUIC. However, running an 890 | additional congestion control algorithm at the application layer can have 891 | unintended effects due to the interaction of two *nested* congestion 892 | controllers. 893 | 894 | If an RTP application paces its media transmission at a rate that does not saturate path bandwidth, 895 | more heavy-handed congestion control mechanisms (drastic 896 | reductions in the sending rate when loss is detected, with much slower increases 897 | when losses are no longer being detected) ought to rarely come into play. If an RTP 898 | application chooses RoQ as its transport, sends enough media to saturate the available 899 | path bandwidth, and does not adapt its sending rate, these drastic measures will be 900 | required to avoid sustained or oscillating congestion along the path. 901 | 902 | Thus, applications are advised to only use the bandwidth estimation without 903 | running the complete congestion control algorithm at the application layer 904 | before passing data to the QUIC layer. 905 | 906 | The bandwidth estimation algorithm typically needs some feedback on the 907 | transmission performance. This feedback can be collected via RTCP or following 908 | the guidelines in {{rtcp-mapping}} and {{api-considerations}}. 909 | 910 | ## Sharing QUIC connections {#shared-connections} 911 | 912 | Two endpoints can establish channels to exchange more than one type of 913 | data simultaneously. The channels can be intended to carry real-time RTP data or 914 | other non-real-time data. This can be realized in different ways. 915 | 916 | - One straightforward solution is to establish multiple QUIC connections, one 917 | for each channel, whether the channel is used for real-time media or 918 | non-real-time data. 919 | 920 | - Alternatively, all real-time channels are mapped to one QUIC connection, while 921 | a separate QUIC connection is created for the non-real-time channels. 922 | 923 | - A third option is to multiplex all channels, whether real-time or non-real-time, in a single QUIC connection via an 924 | extension to RoQ. 925 | 926 | In the first two cases, the congestion controllers can be chosen to match the 927 | demands of the respective channels and the different QUIC connections will 928 | compete for the same resources in the network. No local prioritization of data 929 | across the different (types of) channels would be necessary. 930 | 931 | Although it is possible to multiplex (all or a subset of) real-time and 932 | non-real-time channels onto a single, shared QUIC connection by extending RoQ, 933 | the underlying QUIC implementation will likely use the same congestion 934 | controller for all channels in the shared QUIC connection. For this reason, 935 | applications multiplexing real-time and non-real-time channels in one connection 936 | will need to implement some form of prioritization or bandwidth allocation for 937 | the different channels. 938 | 939 | # Guidance on Choosing QUIC Streams, QUIC DATAGRAMs, or a Mixture {#s-d-m-guidance} 940 | 941 | As noted in {{streams-and-datagrams}}, this document does not take a position on using QUIC streams, QUIC DATAGRAMs, or a mixture of both, for any particular RoQ use case or application. It does seem useful to include observations that might guide implementers who will need to make choices about that. 942 | 943 | ## RTP Considerations 944 | 945 | One implementation goal might be to minimize processing overhead, for applications that are migrating from RTP over UDP to RoQ. These applications don't rely on any transport protocol behaviors beyond UDP, which can be described as "IP plus multiplexing". The implementers might be motivated by one or more of the advantages of encapsulating RTP in QUIC that are described in {{motivations}}, but they do not need any of the advantages that would apply when encapsulating RTP in QUIC streams. For these applications, simply placing each RTP packet in a QUIC DATAGRAM frame when it becomes available would be sufficient, using no QUIC streams at all. 946 | 947 | Another implementation goal might be to prioritize specific types of video frames over other types. For these applications, placing each type of video frame in a separate QUIC stream would allow the RoQ receiver to focus on the most important video frames more easily. This also allows the implementer to rely on QUIC's "byte stream" abstraction, freeing the application from dealing with MTU size restrictions, in contrast to the need to fit RTP packets into QUIC DATAGRAMs. The application might use QUIC streams for all of the RTP packets carried over this specific QUIC connection, with no QUIC DATAGRAMs at all. 948 | 949 | Some applications might have implementation goals that don't fit neatly into "QUIC streams only" or "QUIC DATAGRAMs only" categories. For example, another implementation goal might be to use QUIC streams to carry RTP video frames, but to use QUIC DATAGRAMs to carry RTP audio frames, which are typically much smaller. Because humans tend to tolerate inconsistent behavior in video better than inconsistent behavior in audio, the application might add Forward Error Correction {{!RFC6363}} to RTP audio packets and encapsulate the result in QUIC DATAGRAMs, while encapsulating RTP video packets in QUIC streams. 950 | 951 | As noted in {{multiplexing}}, all RoQ streams and RoQ datagrams begin with a flow identifier. This allows a RoQ sender to begin by encapsulating related RTP packets in QUIC streams and then switch to carrying them in QUIC DATAGRAMs, or vice versa. RoQ receivers need to be prepared to accept any valid RTP packet with a given flow identifier, whether it started by being encapsulated in QUIC streams or in QUIC DATAGRAMs, and RoQ receivers need to be prepared to accept RTP flows that switch from QUIC stream encapsulation to QUIC DATAGRAMs, or vice versa. 952 | 953 | Because QUIC provides a capability to migrate connections for various reasons, including recovering from a path failure ({{Section 9 of !RFC9000}}), when a QUIC connection migrates, a RoQ sender has the opportunity to revisit decisions about which RTP packets are encapsulated in QUIC streams, and which RTP packets are encapsulated in QUIC DATAGRAMs. Again, RoQ receivers need to be prepared for this eventuality. 954 | 955 | ## RTCP Considerations {#RTCP-considerations} 956 | 957 | RTCP was originally defined to be used with UDP, which implies (1) 958 | the only buffering present would be at the IP interface level, so that transmission timing is largely under the control of the application, and (2) that the overhead, *avg_rtcp_size*, used to 959 | compute the RTCP transmission interval could be deterministically computed by 960 | adding the IP and UDP headers. Both change when carrying RTCP over QUIC and 961 | they change in different ways when using QUIC streams vs. QUIC datagrams. 962 | 963 | ### RTCP over QUIC datagrams {#rtcp-over-datagrams} 964 | 965 | When sending RTCP packets in QUIC datagrams this implies that an RTCP packet may not 966 | be immediately transmitted as it is subject to queuing and multiplexing with RTP 967 | packets and subject to QUIC congestion control. This means that a sending timestamp 968 | added to an RTCP packet, e.g., in an SR packet, may differ in unforeseeable ways 969 | from the actual time when the RTCP packet gets sent into the network while these are 970 | usually fairly close to each other for RTP-over-UDP. Effectively, we have a 971 | application sending timestamp *t_a* and the network transmission timestamp 972 | *t_n*. Applications just have to be aware that RTCP does not measure the network 973 | level RTT but rather the application layer RTT. 974 | 975 | Moreover, the true overhead per RTCP packet cannot easily be determined: this is 976 | because, in addition to adding the IP and UDP headers, the QUIC (short) header 977 | and the QUIC datagram frame header are to be considered but their sizes vary and 978 | it is unknown which other frames may be sent along in the same UDP packet. Any 979 | lower bound that can be determined could be affected by the version of QUIC 980 | being used. An example estimation of the overhead including IP, UDP and QUIC 981 | headers is given in {{overhead-estimation}}. 982 | 983 | It is thus suggested that application developers recognize that per-RTCP packet overhead will always be an estimate, and include IP, UDP, QUIC, and DATAGRAM header sizes as a conservative heuristic. While this value may not be precisely accurate, it follows the example of RTP over UDP in {{!RFC3550}}, which includes the RTP and UDP header sizes, and adding the additional QUIC and DATAGRAM header sizes avoids the immediate problem of significantly understating avg_rtcp_size, resulting in an underestimate of the cost of sending additional RTCP reports. 984 | 985 | ### RTCP over QUIC streams {#rtcp-over-streams} 986 | 987 | The above considerations from {{rtcp-over-datagrams}} get even more complex when 988 | transmitting RTCP reliably over QUIC streams: it is unknown if (and how many) 989 | retransmissions occurred. 990 | 991 | For RTT computations, again, this means that the application must consider that 992 | it observes the application layer RTT including retransmissions, where 993 | retransmissions also contribute to the observed jitter. 994 | 995 | For overhead computation, retransmissions are not explicitly considered nor is 996 | the multiplexing with other streams. 997 | 998 | To keep the complexity under control, it is again suggested that application developers recognize that per-RTCP packet overhead will always be an estimate, and these estimates should include plausible values for IP, UDP, QUIC, and QUIC STREAM frame header sizes. While this value may not be precisely accurate, it follows the example of RoQ over DATAGRAMs in {{rtcp-over-datagrams}}}, and again avoids the immediate problem of significantly understating avg_rtcp_size, resulting in an underestimate of the cost of sending additional RTCP reports. 999 | 1000 | ### Mixed operations 1001 | 1002 | As noted in {{s-d-m-guidance}}, applications may use QUIC streams, QUIC DATAGRAMs, or a mixture, and this extends to choices for RTP and RTCP. While applications may, in principle, mix sending RTP and RTCP via QUIC streams and via QUIC DATAGRAMs, doing so has unforeseeable implications on timing and reordering and 1003 | overhead. 1004 | 1005 | Using the same QUIC primitives for both RTP and 1006 | RTCP when transporting a single media stream will be safer than mixing QUIC primitives - for example, using QUIC streams to carry RTP media payloads and QUIC DATAGRAMs to carry RTCP, or vice versa. If an application uses both streams and datagrams to selectively obtain 1007 | reliable transmission for some RTP media payloads but not for others, it is strongly suggested that the application developer 1008 | knowingly choose which RTT observations they are interested in, while remaining aware of the advice included in {{RTCP-considerations}}. 1009 | 1010 | Even this awareness may not be "safe enough" - for example, {{RFC9221}} allows QUIC DATAGRAM frames to be coalesced with other QUIC frames, and recommends, but does not require, QUIC DATAGRAMs to be sent as soon as possible, or to be delivered to a receiving application immediately. {{RFC9221}} also recommends, but does not require, a QUIC implementation to provide an API for prioritization between QUIC streams and QUIC DATAGRAMs. 1011 | 1012 | # Replacing RTCP and RTP Header Extensions with QUIC Feedback {#rtcp-mapping} 1013 | 1014 | Because RTP has so often used UDP as its underlying transport protocol, 1015 | receiving little or no transport feedback, existing RTP implementations rely on feedback 1016 | from the RTP Control Protocol (RTCP) so that RTP senders and receivers can 1017 | exchange control information to monitor connection statistics and to identify 1018 | and synchronize media streams. 1019 | 1020 | Because QUIC can provide transport-level feedback, it can replace at least some RTP 1021 | transport-level feedback with current QUIC feedback {{!RFC9000}}. In addition, 1022 | RTP-level feedback that is not available in QUIC by default can potentially be 1023 | replaced with feedback provided by useful QUIC extensions in the future as described in 1024 | {{rtcp-quic-ext-examples}}. 1025 | 1026 | When statistics contained in RTCP packets are also available from QUIC or can be 1027 | derived from statistics available from QUIC, it is desirable to provide these 1028 | statistics at only one protocol layer. This avoids consumption of bandwidth to 1029 | deliver equivalent control information at more than one level of the protocol 1030 | stack. QUIC and RTCP both have rules describing when certain signals are to be 1031 | sent. This document does not change any of the rules described by either 1032 | protocol. Rather, it specifies a baseline for replacing some of the RTCP packet types 1033 | by mapping the contents to QUIC connection statistics, and reducing the 1034 | transmission frequency and bandwidth requirements for some RTCP packet types 1035 | that must be transmitted periodically. Future documents can extend this mapping 1036 | for other RTCP format types and can make use of new QUIC extensions that become 1037 | available over time. The mechanisms described in this section can enhance the 1038 | statistics provided by RTCP and reduce the bandwidth overhead required by 1039 | certain RTCP packets. Applications using RoQ still need to adhere to the rules for 1040 | RTCP feedback given by {{!RFC3550}} and the RTP profiles in use. 1041 | 1042 | Most statements about "QUIC" in {{rtcp-mapping}} are applicable to both RTP 1043 | packets encapsulated in QUIC streams and RTP packets encapsulated in DATAGRAMs. 1044 | The differences are described in {{roc-d}} and {{roc-s}}. 1045 | 1046 | While RoQ places no restrictions on applications sending RTCP, this document assumes that the reason an implementer chooses to support RoQ is to obtain benefits beyond what's available when RTP uses UDP as its underlying transport layer. 1047 | Exposing relevant information from the QUIC layer to the application instead of exchanging additional RTCP packets, where applicable, will reduce processing and bandwidth overhead for RoQ senders and receivers. 1048 | 1049 | {{transport-layer-feedback}} discusses what information can be exposed from the 1050 | QUIC connection layer to reduce the RTCP overhead. 1051 | 1052 | ## RoQ Datagrams {#roc-d} 1053 | 1054 | QUIC DATAGRAMs are ACK-eliciting packets, which means that an acknowledgment is 1055 | triggered when a DATAGRAM frame is received. Thus, a sender can assume that an 1056 | RTP packet arrived at the receiver or was lost in transit, using the QUIC 1057 | acknowledgments of QUIC DATAGRAM frames. In the following, an RTP packet is 1058 | regarded as acknowledged when the QUIC DATAGRAM frame that carried the RTP 1059 | packet was acknowledged. 1060 | 1061 | ## RoQ Streams {#roc-s} 1062 | 1063 | For RTP packets that are sent over QUIC streams, an RTP packet is considered 1064 | acknowledged after all STREAM frames that carried parts of the RTP packet were 1065 | acknowledged. 1066 | 1067 | When QUIC streams are used, the implementer needs to be aware that the direct 1068 | mapping proposed below might not reflect the real characteristics of the network. 1069 | RTP packet loss can seem lower than actual packet loss due to QUIC's automatic 1070 | retransmissions. Similarly, timing information can be incorrect due to 1071 | retransmissions or transmission delays introduced by the QUIC stack. 1072 | 1073 | ## Multihop Topologies {#multi-hop} 1074 | 1075 | In some topologies, RoQ might only be used on some of the links between multiple 1076 | session participants. Other links might be using RTP over UDP, or over some other 1077 | supported RTP encapsulation protocol, and some participants might be using RTP 1078 | implementations that don't support RoQ at all. These participants will not be 1079 | able to infer feedback from QUIC, and they might receive less RTCP feedback than 1080 | expected. This situation can arise when participants using RoQ are not aware that 1081 | other participants are not using RoQ and minimize their use of RTCP, 1082 | assuming their RoQ peer will be able to infer statistics from QUIC. There are 1083 | two ways to solve this problem: 1084 | 1085 | * If the middlebox translating between RoQ and RTP 1086 | over other RTP transport protocols such as UDP or TCP provides Back-to-Back RTP 1087 | sessions as described in {{Section 3.2.2 of !RFC7667}}, this middlebox can add 1088 | RTCP packets for the participants not using RoQ by using the statistics the 1089 | middlebox gets from QUIC and the mappings described in the following sections. 1090 | * If the middlebox does not provide Back-to-Back RTP sessions, participants can 1091 | use additional signaling to let the RoQ participants know what RTCP is 1092 | required. 1093 | 1094 | ## Feedback Mappings {#transport-layer-feedback} 1095 | 1096 | This section explains how some of the RTCP packet types that are used to signal 1097 | reception statistics can be replaced by equivalent statistics that are already 1098 | collected by QUIC. The following list explains how this mapping can be achieved 1099 | for the individual fields of different RTCP packet types. 1100 | 1101 | The list of RTCP packets in this section is not exhaustive, and similar considerations would apply when exchanging any other type of RTCP control packets using RoQ. 1102 | 1103 | A more thorough analysis including the information that cannot be mapped from 1104 | QUIC can be found in {{rtcp-analysis}}: RTCP Control Packet Types (in 1105 | {{control-packets}}), Generic RTP Feedback (RTPFB) (in {{generic-feedback}}), 1106 | Payload-specific RTP Feedback (PSFB) (in {{payload-specific-feedback}}), 1107 | Extended Reports (in {{extended-reports}}), and RTP Header Extensions (in 1108 | {{rtp-header-extensions}}). 1109 | 1110 | ### Negative Acknowledgments ("NACK") {#NACK-mappings} 1111 | 1112 | Generic *Negative Acknowledgments* (`PT=205`, `FMT=1`, `Name=Generic NACK`, 1113 | {{!RFC4585}}) contain information about RTP packets which the receiver 1114 | considered lost. {{Section 6.2.1. of !RFC4585}} recommends using this feature 1115 | only if the underlying protocol cannot provide similar feedback. QUIC does not 1116 | provide negative acknowledgments but can detect lost packets based on the Gap 1117 | numbers contained in QUIC ACK frames ({{Section 6 of !RFC9002}}). 1118 | 1119 | ### ECN Feedback ("ECN") {#ECN-mappings} 1120 | 1121 | *ECN Feedback* (`PT=205`, `FMT=8`, `Name=RTCP-ECN-FB`, {{!RFC6679}}) packets report the count of observed ECN-CE marks. 1122 | {{!RFC6679}} defines two RTCP reports, one packet type (with `PT=205` and `FMT=8`), and a new report block for the extended reports. 1123 | QUIC supports ECN reporting through acknowledgments. 1124 | If the QUIC connection supports ECN, using QUIC acknowledgments to report ECN counts, rather than RTCP ECN feedback reports, reduces bandwidth and processing demands on the RTCP implementation. 1125 | 1126 | ### Goodbye Packets ("BYE") {#BYE-mapping} 1127 | 1128 | RTP session participants can use *Goodbye* RTCP packets (`PT=203`, `Name=BYE`, 1129 | {{!RFC3550}}), to indicate that a source is no longer active. If the participant 1130 | is also going to close the QUIC connection, the *BYE* packet can be replaced by 1131 | a QUIC CONNECTION_CLOSE frame. In this case, the reason for leaving can be 1132 | transmitted in QUIC's CONNECTION_CLOSE *Reason Phrase*. However, if the 1133 | participant wishes to use this QUIC connection for any other multiplexed 1134 | traffic, the participant has to use the BYE packet because the QUIC 1135 | CONNECTION_CLOSE would close the entire QUIC connection for all other QUIC 1136 | streams and DATAGRAMs. 1137 | 1138 | # RoQ-QUIC and RoQ-RTP API Considerations {#api-considerations} 1139 | 1140 | The mapping described in the previous sections relies on the QUIC implementation passing some information to the RoQ implementation. 1141 | Although RoQ will function without this information, some 1142 | optimizations regarding rate adaptation and RTCP mapping require certain 1143 | functionalities to be exposed to the application. 1144 | 1145 | Each item in the following list can be considered individually. Any exposed 1146 | information or function can be used by RoQ regardless of whether the other items 1147 | are available. Thus, RoQ does not depend on the availability of all of the 1148 | listed features but can apply different optimizations depending on the 1149 | functionality exposed by the QUIC implementation. 1150 | 1151 | * *initial_max_data transport*: If the QUIC receiver has indicated a willingness to accept 1152 | 0-RTT packets with early data, this is the maximum size that the QUIC sender can use, 1153 | as described in {{ed-considerations}}. 1154 | * *Maximum Datagram Size*: The maximum DATAGRAM size that the QUIC connection 1155 | can transmit on the network path to the QUIC receiver. If a RoQ sender using 1156 | DATAGRAMs does not know the maximum DATAGRAM size for the path to the RoQ 1157 | receiver, there are only two choices - either use heuristics to limit the size 1158 | of RoQ messages, or be prepared to lose RoQ messages that were too large to be 1159 | carried through the network path and delivered to the RoQ receiver. 1160 | * *Datagram Acknowledgment and Loss*: {{Section 5.2 of !RFC9221}} allows QUIC 1161 | implementations to notify the application that a DATAGRAM was 1162 | acknowledged or that it believes a DATAGRAM was lost. Given the DATAGRAM 1163 | acknowledgments and losses, the application can deduce which RTP packets 1164 | arrived at the receiver and which were lost (see also {{roc-d}}). 1165 | * *Stream States*: The stream states include which parts of the data sent on a 1166 | stream were successfully delivered and which are still outstanding to be sent 1167 | or retransmitted. If an application keeps track of the RTP packets sent on a 1168 | stream, their respective sizes, and in which order they were transmitted, it 1169 | can infer which RTP packets were acknowledged according to the definition in 1170 | {{roc-s}}. 1171 | * *Arrival timestamps*: If the QUIC connection uses a timestamp extension like 1172 | {{?I-D.draft-smith-quic-receive-ts}} or {{?I-D.draft-huitema-quic-ts}}, the 1173 | arrival timestamps or one-way delays can support the application as described 1174 | in {{rtcp-mapping}} and {{congestion-control}}. 1175 | * *Bandwidth Estimation*: If a bandwidth estimate is available in the QUIC 1176 | implementation, exposing it avoids the overhead of executing an additional 1177 | bandwidth estimation algorithm in the application. 1178 | * *ECN*: If ECN marks are available, they can support the bandwidth estimation 1179 | of the application. 1180 | * *RTT*: The RTT estimations as described in {{Section 5 of !RFC9002}}. 1181 | 1182 | One goal for the RoQ protocol is to shield RTP applications from the details of QUIC encapsulation, so the RTP application doesn't need much information about QUIC from RoQ, but some information will be valuable. For example, it could be desirable that the RoQ implementation provides an indication of connection migration to the RTP application. 1183 | 1184 | Because RTP applications do use the application timestamps contained in RTCP packets in a variety of ways, a RoQ implementation that provides and event-driven API can allow RoQ applications to generate RTCP packets "at the last moment", when the RoQ application is able to send the RTCP packet, and allow RoQ applications to notice that QUIC congestion control is limiting the ability of the RoQ application to send RTCP packets without this delay. 1185 | 1186 | # Discussion 1187 | 1188 | This section contains topics that are worth mentioning, but don't fit well into other sections of the document. 1189 | 1190 | ## Impact of Connection Migration 1191 | 1192 | RTP sessions are characterized by a continuous flow of RTP packets in either or 1193 | both directions. A connection migration might lead to pausing media 1194 | transmission until reachability of the peer under the new address is validated. 1195 | This might lead to short breaks in media delivery in the order of RTT and, if 1196 | RTCP is used for RTT measurements, might cause spikes in observed delays. 1197 | Application layer congestion control mechanisms (and packet repair schemes 1198 | such as retransmissions) need to be prepared to cope with such spikes. As noted in {{api-considerations}}, it could be desirable that the RoQ implementation provides an indication of connection migration to the RTP application, to assist in coping. 1199 | 1200 | ## 0-RTT and Early Data considerations {#ed-considerations} 1201 | 1202 | RoQ applications, like any other RTP applications, want to establish a media path quickly, reducing clipping at the beginning of a conversation. For repeated connections between endpoints that have previously carried out a full TLS handshake procedure, the initiator of a QUIC connection can 1203 | use 0-RTT packets with "early data" to include application data in a packet that is used to establish a connection. 1204 | 1205 | As 0-RTT packets are subject to replay attacks, RoQ applications MUST carefully specify which data types and operations 1206 | are allowed. 1207 | 1208 | {{Section 9.2 of !RFC9001}} says 1209 | 1210 | > Application protocols MUST either prohibit the use of extensions that carry application semantics in 0-RTT or provide replay mitigation strategies. 1211 | 1212 | For the purposes of this discussion, RoQ is an application protocol that allows the use of 0-RTT. 1213 | 1214 | RoQ application developers ought to take the considerations described in {{rej-ed}} and {{replay-ed}} into account when deciding whether to use 0-RTT with early data for an application. 1215 | 1216 | ### Effect of 0-RTT Rejection for RoQ using Early Data {#rej-ed} 1217 | 1218 | If the goal for using early data is to reduce clipping, a QUIC endpoint is relying on the other QUIC endpoint to accept the 0-RTT packet carrying early data containing media. 1219 | 1220 | A QUIC endpoint indicates its willingness to accept a 0-RTT packet containing early data by sending the TLS early_data extension in the NewSessionTicket message with the max_early_data_size parameter set to the sentinel value 0xffffffff. 1221 | The amount of data that a QUIC client can send in QUIC 0-RTT is controlled by the initial_max_data transport parameter supplied by the QUIC server. 1222 | This is described in more detail in {{Section 4.6.1 of !RFC9001}}. 1223 | 1224 | If a QUIC endpoint is not willing to accept a 0-RTT packet containing early data, but receives one anyway, the QUIC endpoint rejects the 0-RTT packet by sending EncryptedExtensions without an early_data extension. This is described in more detail, in {{Section 4.6.2 of !RFC9001}}. 1225 | This necessarily means that a QUIC endpoint attempting to convey RoQ media is now subject to at least one additional RTT delay, as it must send a QUIC Initial packet and perform a full QUIC handshake before it can send RoQ media. 1226 | 1227 | ### Effect of 0-RTT Replay Attacks for RoQ using Early Data {#replay-ed} 1228 | 1229 | Including "early data" in the packet payload in any QUIC 0-RTT packet exposes the application to an additional risk, of accepting "early data" from a 0-RTT packet that has been replayed. 1230 | 1231 | While it is true that 1232 | 1233 | - RTP typically carries ephemeral media contents that is rendered and possibly recorded but otherwise causes no side effects, 1234 | 1235 | - the amount of data that can be carried as packet payload in a 0-RTT packet is rather limited, and 1236 | 1237 | - RTP implementations are likely to discard any replayed media packets as duplicates, 1238 | 1239 | it is still the responsibility of the RoQ application to determine whether the benefits of using 0-RTT with early data outweigh the risks. 1240 | 1241 | Since the QUIC connection will often be created in the context 1242 | of an existing signaling relationship (e.g., using WebRTC or SIP), a careful RoQ implementer can exchange specific 0-RTT 1243 | keying material to prevent replays across sessions. 1244 | 1245 | ## Coalescing RTP packets in a single QUIC packet {#coalescing-packets} 1246 | 1247 | Applications have some control over how the QUIC stack maps application data to 1248 | QUIC frames, but applications cannot control how the QUIC stack maps STREAM and 1249 | DATAGRAM frames to QUIC packets {{Section 13 of ?RFC9000}} and {{Section 5 of 1250 | ?RFC9308}}. 1251 | 1252 | * When RTP payloads are carried over QUIC streams, the RTP payload is treated as 1253 | an ordered byte stream that will be carried in QUIC STREAM frames, with no 1254 | effort to match application data boundaries. 1255 | * When RTP payloads are carried over DATAGRAMs, each RTP payload data unit 1256 | is mapped into a DATAGRAM frame, but 1257 | * QUIC implementations can include multiple STREAM frames from different streams 1258 | and one or more DATAGRAM frames into a single QUIC packet, and can include 1259 | other QUIC frames as well. 1260 | 1261 | QUIC stacks are allowed to wait for a short period of time if the queued QUIC 1262 | packet is shorter than the Path MTU, in order to optimize for bandwidth 1263 | utilization instead of latency, while real-time applications usually prefer to 1264 | optimize for latency rather than bandwidth utilization. This waiting interval is 1265 | under the QUIC implementation's control, and could be based on knowledge about 1266 | application sending behavior or heuristics to determine whether and for how long 1267 | to wait. 1268 | 1269 | When there are a lot of small DATAGRAM frames (e.g., an audio stream) and a lot 1270 | of large DATAGRAM frames (e.g., a video stream), it could be a good idea to make sure the 1271 | audio frames can be included in a QUIC packet that also carries video frames 1272 | (i.e., the video frames don't fill the whole QUIC packet). Otherwise, the QUIC 1273 | stack might have to send additional small packets only carrying single audio 1274 | frames, which would waste some bandwidth. 1275 | 1276 | Application designers are advised to take these considerations into account when 1277 | selecting and configuring a QUIC stack for use with RoQ. 1278 | 1279 | # Directions for Future Work {#futures} 1280 | 1281 | This document describes RoQ in sufficient detail that an implementer can build a RoQ application, but we recognize that additional work is likely, after we have sufficient experience with RoQ to guide that work ({{futures-impl-deploy}}) and as new QUIC extensions become available ({{futures-new-ext}}). 1282 | 1283 | ## Future Work Resulting from Implementation and Deployment Experience {#futures-impl-deploy} 1284 | 1285 | Possible directions would include 1286 | 1287 | * More guidance on transport for RTCP (for example, when to use QUIC streams vs. DATAGRAMs) including guidance on prioritization between streams and DATAGRAMs for the performance of RTCP. 1288 | 1289 | * More guidance on the use of real-time-friendly congestion control algorithms (for example, Copa {{Copa}}, L4S {{?RFC9330}}, etc.). 1290 | 1291 | * More guidance for congestion control and rate adaptation for multiple RoQ flows (whether streams or datagrams). 1292 | 1293 | * Possible guidance for connection sharing between real-time and non-real-time flows, including considerations for congestion control and rate adaptation, scheduling, prioritization, and which ALPNs to use. 1294 | 1295 | * Investigation of the effects of delaying or dropping DATAGRAMs due to congestion before they can be transmitted by the QUIC stack. 1296 | 1297 | * Implementation of translating middleboxes for translating between RoQ and RTP over UDP. As described in {{topologies}}, RoQ can be used to connect to some RTP middleboxes using some topologies, and these middleboxes might be connecting RoQ endpoints and non-RoQ endpoints, so will need to translate between RoQ and RTP over UDP. 1298 | 1299 | For these reasons, publication of this document as a stable reference for implementers to test with, and report results, seems useful. 1300 | 1301 | ## Future Work Resulting from New QUIC Extensions {#futures-new-ext} 1302 | 1303 | In addition, as noted in {{new-quic}}, one of the motivations for using QUIC as a transport for RTP is to exploit new QUIC extensions as they become available. We noted several specific proposed QUIC extensions in {{optional-extensions}}, but these proposals are all solving relevant problems, and those problems are worth solving for the QUIC protocol, whether the listed proposals are used in the solution or not. 1304 | 1305 | * Guidance for using RoQ with QUIC connection migration and over multiple paths. QUIC connection migration was already defined in {{!RFC9000}}, and the Multipath Extension for QUIC {{?I-D.draft-ietf-quic-multipath}} has been adopted and is relatively mature, so this is likely to be the first new QUIC extension we address. 1306 | 1307 | * Guidance for using RoQ with QUIC NAT traversal solutions. This could use Interactive Connectivity Establishment (ICE) {{?RFC8445}} or other NAT traversal solutions. 1308 | 1309 | * Guidance for improved jitter calculations to use with congestion control and rate adaptation. 1310 | 1311 | * Guidance for other aspects of QUIC performance optimization relying on extensions. 1312 | 1313 | Other QUIC extensions, not yet proposed, might also be useful with RoQ. 1314 | 1315 | # Implementation Status 1316 | 1317 | > **RFC Editor's note:** Please remove this section prior to publication of a 1318 | > final version of this document. 1319 | 1320 | This section records the status of known implementations of the protocol defined 1321 | by this specification at the time of posting of this Internet-Draft, and is 1322 | based on a proposal described in {{?RFC7942}}. The description of 1323 | implementations in this section is intended to assist the IETF in its decision 1324 | processes in progressing drafts to RFCs. Please note that the listing of any 1325 | individual implementation here does not imply endorsement by the IETF. 1326 | Furthermore, no effort has been spent to verify the information presented here 1327 | that was supplied by IETF contributors. This is not intended as, and must not be 1328 | construed to be, a catalog of available implementations or their features. 1329 | Readers are advised to note that other implementations may exist. 1330 | 1331 | According to {{?RFC7942}}, "this will allow reviewers and working groups to 1332 | assign due consideration to documents that have the benefit of running code, 1333 | which may serve as evidence of valuable experimentation and feedback that have 1334 | made the implemented protocols more mature. It is up to the individual working 1335 | groups to use this information as they see fit". 1336 | 1337 | ## mengelbart/roq 1338 | 1339 | Ogranization: 1340 | : Technical University of Munich 1341 | 1342 | Implementation: 1343 | : {{roq}} 1344 | 1345 | Description: 1346 | : *roq* is a library implementing the basic encapsulation described in 1347 | {{encapsulation}}. The library uses the Go programming language and supports the 1348 | {{quic-go}} QUIC implementation. 1349 | 1350 | Level of Maturity: 1351 | : prototype 1352 | 1353 | Coverage: : The library supports sending and receiving RTP and RTCP packets 1354 | using QUIC streams and QUIC DATAGRAMs, and supports multiplexing using flow 1355 | identifiers. Applications using the library are responsible for appropriate 1356 | signaling, setting up QUIC connections, and managing RTP sessions. Applications 1357 | choose whether to send RTP and RTCP packets over streams or DATAGRAMs, and 1358 | applications also have control over the QUIC and RTP congestion controllers in 1359 | use since they control the QUIC connection setup and can thus configure the QUIC 1360 | stack they use to their preferences. 1361 | 1362 | Version Compatibility: 1363 | : The library implements {{?I-D.draft-ietf-avtcore-rtp-over-quic-12}}. 1364 | 1365 | Licensing: 1366 | : MIT License 1367 | 1368 | Implementation Experience: 1369 | : The implementer reports they have no experience with the topics discussed in 1370 | {{futures}}. RoQ relies on out-of-band signaling for connection establishment, 1371 | and since there is currently no specification for SDP for RoQ, applications 1372 | using the library have to statically configure connection information to allow 1373 | testing 1374 | 1375 | Contact Information: 1376 | : Mathis Engelbart (mathis.engelbart@gmail.com) 1377 | 1378 | Last Updated: 1379 | : 07 January 2025 1380 | 1381 | ## bbc/gst-roq 1382 | 1383 | Ogranization: 1384 | : BBC Research and Development 1385 | 1386 | Implementation: 1387 | : RTP-over-QUIC elements for GStreamer {{gst-roq}} 1388 | 1389 | Description: 1390 | : *gst-quic-transport* provides a set of GStreamer plugins implementing QUIC 1391 | transport. *gst-roq* provides a set of GStreamer plugins implementing RoQ. 1392 | 1393 | Level of Maturity: 1394 | : research 1395 | 1396 | Coverage: 1397 | : The plugins support sending and receiving RTP and RTCP packets using QUIC 1398 | streams and QUIC DATAGRAMs, and supports multiplexing using flow identifiers. 1399 | GStreamer pipelines that use the RoQ plugins found in the *gst-roq* repository 1400 | can make use of the plugins found in the *gst-quic-transport* repository to set 1401 | up QUIC connections. RTP sessions can be managed by existing GStreamer plugins 1402 | available in the standard GStreamer release. GStreamer pipeline applications 1403 | choose whether to send RTP and RTCP packets over streams or DATAGRAMs. 1404 | 1405 | Version Compatibility: 1406 | : The library implements {{?I-D.draft-ietf-avtcore-rtp-over-quic-05}}. 1407 | 1408 | Licensing: 1409 | : GNU Lesser General Public License v2.1 1410 | 1411 | Implementation Experience: 1412 | : The implementer reports they have no experience with the topics discussed in 1413 | {{futures}}. Both in-band and out-of-band signalling for RoQ media sessions is 1414 | in active development via an implementation of {{?I-D.draft-hurst-sip-quic-00}}, 1415 | which re-uses the GStreamer plugins described above. 1416 | 1417 | Contact Information: 1418 | : Sam Hurst (sam.hurst@bbc.co.uk) 1419 | 1420 | Last Updated: 1421 | : 05 June 2024 1422 | 1423 | ## mengelbart/rtp-over-quic 1424 | 1425 | Ogranization: 1426 | : Technical University of Munich 1427 | 1428 | Implementation: 1429 | : RTP over QUIC {{RTP-over-QUIC}} 1430 | 1431 | Description: 1432 | : *RTP over QUIC* is a experimental implementation of the mapping described in 1433 | an earlier version of this document. 1434 | 1435 | Level of Maturity: 1436 | : research 1437 | 1438 | Coverage: 1439 | : The application implements the RoQ DATAGRAMs mapping and implements SCReAM 1440 | congestion control at the application layer. It can optionally disable the 1441 | built-in QUIC congestion control (NewReno). The endpoints only use RTCP for 1442 | congestion control feedback, which can optionally be disabled and replaced by 1443 | the QUIC connection statistics as described in {{transport-layer-feedback}}. 1444 | Experimental results of the implementation can be found in {{RoQ-Mininet}}. 1445 | 1446 | Version Compatibility: 1447 | : {{?I-D.draft-ietf-avtcore-rtp-over-quic-00}} 1448 | 1449 | Licensing: 1450 | : MIT 1451 | 1452 | Implementation Experience: 1453 | : See {{RoQ-Mininet}} 1454 | 1455 | Contact Information: 1456 | : Mathis Engelbart (mathis.engelbart@gmail.com) 1457 | 1458 | Last Updated: 1459 | : 25 May 2024 1460 | 1461 | ## meetecho/imquic 1462 | 1463 | Ogranization: 1464 | : Meetecho 1465 | 1466 | Implementation: 1467 | : imquic {{imquic}} 1468 | 1469 | Description: 1470 | : QUIC library with RTP Over QUIC (RoQ) and Media Over QUIC (MoQT) support 1471 | 1472 | Level of Maturity: 1473 | : alpha 1474 | 1475 | Coverage: 1476 | : The library supports sending and receiving RTP and RTCP packets using QUIC 1477 | streams and QUIC DATAGRAMs, and supports multiplexing using flow identifiers. 1478 | Applications using the library are responsible for appropriate signaling, 1479 | setting up QUIC connections, and managing RTP sessions. Applications choose 1480 | whether to send RTP and RTCP packets over streams or DATAGRAMs. Basic client and 1481 | server examples are available as a demo, and the library was also used to test 1482 | interoperability with WebRTC via an open source gateway. 1483 | 1484 | Version Compatibility: 1485 | : {{?I-D.draft-ietf-avtcore-rtp-over-quic-12}} 1486 | 1487 | Licensing: 1488 | : MIT 1489 | 1490 | Implementation Experience: 1491 | : 1492 | 1493 | Contact Information: 1494 | : Lorenzo Miniero (lorenzo@meetecho.com) 1495 | 1496 | Last Updated: 1497 | : 07 January 2025 1498 | 1499 | ## gstreamer/gst-plugin-quinn 1500 | 1501 | Organization: 1502 | : asymptotic 1503 | 1504 | Implementation: 1505 | : gst-plugin-quinn {{gst-plugin-quinn}} 1506 | 1507 | Description: 1508 | : GStreamer plugin with support for QUIC and RTP Over QUIC (RoQ) 1509 | 1510 | Level of Maturity: 1511 | : alpha 1512 | 1513 | Coverage: 1514 | : The library supports sending and receiving RTP packets using QUIC streams and 1515 | QUIC DATAGRAMs, and supports multiplexing using flow identifiers. Using stream 1516 | per packet is not supported at the moment. Applications using this GStreamer 1517 | plugin are responsible for any required out-of-band signalling, and managing 1518 | RTP sessions. `quinnquicmux` and `quinnquicdemux` provide RoQ functionality with 1519 | the QUIC transport handled by `quinnquicsink` and `quinnquicsrc` plugins. 1520 | Applications can choose whether to send RTP packets over streams or DATAGRAMs. 1521 | Basic examples are available in the repository. 1522 | 1523 | Version Compatibility: 1524 | : {{?I-D.draft-ietf-avtcore-rtp-over-quic-12}} 1525 | 1526 | Licensing: 1527 | : MPL 1528 | 1529 | Implementation Experience: 1530 | : 1531 | 1532 | Contact Information: 1533 | : Sanchayan Maity (sanchayan@asymptotic.io) 1534 | : Arun Raghavan (arun@asymptotic.io) 1535 | 1536 | Last Updated: 1537 | : 21 March 2025 1538 | 1539 | # Security Considerations {#sec-considerations} 1540 | 1541 | RoQ is subject to the security considerations of RTP described in 1542 | {{Section 9 of !RFC3550}} and the security considerations of any RTP profile in 1543 | use. 1544 | 1545 | The security considerations for the QUIC protocol and DATAGRAM extension 1546 | described in {{Section 21 of !RFC9000}}, {{Section 9 of !RFC9001}}, {{Section 8 1547 | of !RFC9002}} and {{Section 6 of !RFC9221}} also apply to RoQ. 1548 | 1549 | Note that RoQ provides mandatory security, and other RTP transports do 1550 | not. In order to prevent the inadvertent disclosure of RTP sessions to 1551 | unintended third parties, RTP topologies described in {{topologies}} that 1552 | include middleboxes supporting both RoQ and non-RoQ paths 1553 | MUST forward RTP packets on non-RoQ paths using a secure AVP profile 1554 | ({{?RFC3711}}, {{?RFC4585}}, or another AVP profile providing equivalent 1555 | RTP-level security), whether or not RoQ senders are using a secure AVP 1556 | profile for those RTP packets. 1557 | 1558 | # IANA Considerations {#iana-considerations} 1559 | 1560 | This document registers a new ALPN protocol ID (in {{iana-alpn}}) and creates a 1561 | new registry that manages the assignment of error code points in RoQ (in 1562 | {{iana-error-codes}}). 1563 | 1564 | ## Registration of a RoQ Identification String {#iana-alpn} 1565 | 1566 | This document creates a new registration for the identification of RoQ 1567 | in the "TLS Application-Layer Protocol Negotiation (ALPN) Protocol IDs" registry 1568 | {{?RFC7301}}. 1569 | 1570 | The "roq" string identifies RoQ: 1571 | 1572 | Protocol: 1573 | : RTP over QUIC (RoQ) 1574 | 1575 | Identification Sequence: 1576 | : 0x72 0x6F 0x71 ("roq") 1577 | 1578 | Specification: 1579 | : This document 1580 | 1581 | ## RoQ Error Codes Registry {#iana-error-codes} 1582 | 1583 | This document establishes a registry for RoQ error codes. The "RTP over QUIC 1584 | (RoQ) Error Codes" registry manages a 62-bit space and is listed under the 1585 | "Real-Time Transport Protocol (RTP) Parameters" registry group. 1586 | 1587 | The new error codes registry created in this document operates under the QUIC 1588 | registration policy documented in {{Section 22.1 of !RFC9000}}. This registry 1589 | includes the common set of fields listed in {{Section 22.1.1 of !RFC9000}}. 1590 | 1591 | Permanent registrations in this registry are assigned using the Specification 1592 | Required policy ({{!RFC8126}}), except for values between 0x00 and 0x3f (in 1593 | hexadecimal; inclusive), which are assigned using Standards Action or IESG 1594 | Approval as defined in {{Sections 4.9 and 4.10 of !RFC8126}}. 1595 | 1596 | Registrations for error codes are required to include a description of the error 1597 | code. An expert reviewer is advised to examine new registrations for possible 1598 | duplication or interaction with existing error codes. 1599 | 1600 | In addition to common fields as described in Section {{Section 22.1 of 1601 | !RFC9000}}, this registry includes two additional fields. Permanent 1602 | registrations in this registry MUST include the following fields: 1603 | 1604 | Name: 1605 | : A name for the error code. 1606 | 1607 | Description: 1608 | : A brief description of the error code semantics, which can be a summary if a 1609 | specification reference is provided. 1610 | 1611 | The initial allocations in this registry are all assigned permanent status and 1612 | list a change controller of the IETF and a contact of the AVTCORE working group 1613 | (avt@ietf.org). 1614 | 1615 | The entries in {{tab-error-codes}} are registered by this document. 1616 | 1617 | | Value | Name | Description | Specification | 1618 | | ------ | ----------------------------- | -------------------------------------- | ------------------ | 1619 | | 0x00 | ROQ\_NO\_ERROR | No Error | {{error-handling}} | 1620 | | 0x01 | ROQ\_GENERAL\_ERROR | General error | {{error-handling}} | 1621 | | 0x02 | ROQ\_INTERNAL\_ERROR | Internal Error | {{error-handling}} | 1622 | | 0x03 | ROQ\_PACKET\_ERROR | Invalid payload format | {{error-handling}} | 1623 | | 0x04 | ROQ\_STREAM\_CREATION\_ERROR | Invalid stream type | {{error-handling}} | 1624 | | 0x05 | ROQ\_FRAME\_CANCELLED | Frame cancelled | {{error-handling}} | 1625 | | 0x06 | ROQ\_UNKNOWN\_FLOW\_ID | Unknown Flow ID | {{error-handling}} | 1626 | | 0x07 | ROQ\_EXPECTATION\_UNMET | Externally signaled requirement unmet | {{error-handling}} | 1627 | {: #tab-error-codes title="Initial RoQ Error Codes"} 1628 | 1629 | --- back 1630 | 1631 | # List of optional QUIC Extensions {#optional-extensions} 1632 | 1633 | The following is a list of QUIC protocol extensions that could be beneficial for 1634 | RoQ, but are not required by RoQ. 1635 | 1636 | * *An Unreliable Datagram Extension to QUIC* {{?RFC9221}}. Without support for 1637 | unreliable DATAGRAMs, RoQ cannot use the encapsulation specified in 1638 | {{quic-datagrams}}, but can still use QUIC streams as specified in 1639 | {{quic-streams}}. 1640 | * A version of QUIC receive timestamps can be helpful for improved jitter 1641 | calculations and congestion control. If the QUIC connection uses a timestamp 1642 | extension such as *Quic Timestamps For Measuring One-Way Delays* {{?I-D.draft-huitema-quic-ts}} or 1643 | *QUIC Extension for Reporting Packet Receive Timestamps* {{?I-D.draft-smith-quic-receive-ts}}, 1644 | the arrival timestamps or one-way delays could be exposed to 1645 | the application for improved bandwidth estimation or RTCP mappings as 1646 | described in {{rtcp-mapping}} and {{rtcp-analysis}}. 1647 | * *QUIC Acknowledgment Frequency* {{?I-D.draft-ietf-quic-ack-frequency}} can 1648 | be used by a sender to optimize the acknowledgment behavior of the receiver, 1649 | e.g., to optimize congestion control. 1650 | * *Signaling That a QUIC Receiver Has Enough Stream Data* 1651 | {{?I-D.draft-thomson-quic-enough}} and *Reliable QUIC Stream Resets* 1652 | {{?I-D.draft-ietf-quic-reliable-stream-reset}} would allow RoQ senders and 1653 | receivers to use versions of CLOSE\_STREAM and STOP\_SENDING that contain 1654 | offsets. The offset could be used to reliably retransmit all frames up to a 1655 | certain frame that ought to be cancelled before resuming transmission of further 1656 | frames on new QUIC streams. 1657 | 1658 | # Considered RTCP Packet Types and RTP Header Extensions {#rtcp-analysis} 1659 | 1660 | This section lists all the RTCP packet types and RTP header extensions that were 1661 | considered in the analysis described in {{rtcp-mapping}}. 1662 | 1663 | Each subsection in {{rtcp-analysis}} corresponds to an IANA registry, and includes a reference pointing to that registry. 1664 | 1665 | Several but not all of these control packets and their attributes can be mapped 1666 | from QUIC, as described in {{transport-layer-feedback}}. *Mappable from QUIC* 1667 | has one of four values: *yes*, *partly*, *QUIC extension needed*, and *no*. 1668 | *Partly* is used for RTCP packet types for which some fields can be mapped from QUIC, 1669 | but not all. *QUIC extension needed* describes packet types which could be 1670 | mapped with help from one or more QUIC extensions. 1671 | 1672 | Examples of how certain RTCP packet types could be mapped with the help of QUIC 1673 | extensions follow in {{rtcp-quic-ext-examples}}. 1674 | 1675 | ## RTCP Control Packet Types {#control-packets} 1676 | 1677 | The IANA registry for this section is {{IANA-RTCP-PT}}. 1678 | 1679 | | Name | Shortcut | PT | Defining Document | Mappable from QUIC | Comments | 1680 | | ---- | -------- | -- | ----------------- | ---------------- | -------- | 1681 | | SMPTE time-code mapping | SMPTETC | 194 | {{?RFC5484}} | no | | 1682 | | Extended inter-arrival jitter report | IJ | 195 | {{?RFC5450}} | no | Would require send-timestamps, which are not provided by any QUIC extension today | 1683 | | Sender Reports | SR | 200 | {{?RFC3550}} | QUIC extension needed / partly | see {{al-repair}} and {{RR-mappings}} | 1684 | | Receiver Reports | RR | 201 | {{?RFC3550}} | QUIC extension needed | see {{RR-mappings}} | 1685 | | Source description | SDES | 202 | {{?RFC3550}} | no | | 1686 | | Goodbye | BYE | 203 | {{?RFC3550}} | partly | see {{BYE-mapping}} | 1687 | | Application-defined | APP | 204 | {{?RFC3550}} | no | | 1688 | | Generic RTP Feedback | RTPFB | 205 | {{?RFC4585}} | partly | see {{generic-feedback}} | 1689 | | Payload-specific | PSFB | 206 | {{?RFC4585}} | partly | see {{payload-specific-feedback}} | 1690 | | extended report | XR | 207 | {{?RFC3611}} | partly | see {{extended-reports}} | 1691 | | AVB RTCP packet | AVB | 208 | {{IEEE-1733-2011}} | no | | 1692 | | Receiver Summary Information | RSI | 209 | {{?RFC5760}} | no | | 1693 | | Port Mapping | TOKEN | 210 | {{?RFC6284}} | no | | 1694 | | IDMS Settings | IDMS | 211 | {{?RFC7272}} | no | | 1695 | | Reporting Group Reporting Sources | RGRS | 212 | {{?RFC8861}} | no | | 1696 | | Splicing Notification Message | SNM | 213 | {{?RFC8286}} | no | | 1697 | 1698 | ## RTCP XR Block Type {#extended-reports} 1699 | 1700 | The IANA registry for this section is {{IANA-RTCP-XR-BT}}. 1701 | 1702 | | Name | Document | Mappable from QUIC | Comments | 1703 | | ---- | -------- | ---------------- | -------- | 1704 | | Loss RLE Report Block | {{?RFC3611}} | yes | If only used for acknowledgment, could be replaced by QUIC acknowledgments, see {{roc-d}} and {{roc-s}} | 1705 | | Duplicate RLE Report Block | {{?RFC3611}} | no | | 1706 | | Packet Receipt Times Report Block | {{?RFC3611}} | QUIC extension needed / partly | QUIC could provide packet receive timestamps when using a timestamp extension that reports timestamp for every received packet, such as {{?I-D.draft-smith-quic-receive-ts}}. However, QUIC does not provide feedback in RTP timestamp format. | 1707 | | Receiver Reference Time Report Block | {{?RFC3611}} | QUIC extension needed | Used together with DLRR Report Blocks to calculate RTTs of non-senders. RTT measurements can natively be provided by QUIC. | 1708 | | DLRR Report Block | {{?RFC3611}} | QUIC extension needed | Used together with Receiver Reference Time Report Blocks to calculate RTTs of non-senders. RTT can natively be provided by QUIC. | 1709 | | Statistics Summary Report Block | {{?RFC3611}} | QUIC extension needed / partly | RTP packet loss and jitter can be inferred from QUIC acknowledgments, if a timestamp extension is used (see {{?I-D.draft-smith-quic-receive-ts}} or {{?I-D.draft-huitema-quic-ts}}). The remaining fields cannot be mapped to QUIC. | 1710 | | VoIP Metrics Report Block | {{?RFC3611}} | no | as in other reports above, only loss and RTT available | 1711 | | RTCP XR | {{?RFC5093}} | no | | 1712 | | Texas Instruments Extended VoIP Quality Block | | | | 1713 | | Post-repair Loss RLE Report Block | {{?RFC5725}} | no | | 1714 | | Multicast Acquisition Report Block | {{?RFC6332}} | no | | 1715 | | IDMS Report Block | {{?RFC7272}} | no | | 1716 | | ECN Summary Report | {{?RFC6679}} | partly | see {{ECN-mappings}} | 1717 | | Measurement Information Block | {{?RFC6776}} | no | | 1718 | | Packet Delay Variation Metrics Block | {{?RFC6798}} | no | QUIC timestamps can be used to achieve the same goal | 1719 | | Delay Metrics Block | {{?RFC6843}} | no | QUIC has RTT and can provide timestamps for one-way delay, but QUIC timestamps cannot provide end-to-end statistics when QUIC is only used on one segment of the path. | 1720 | | Burst/Gap Loss Summary Statistics Block | {{?RFC7004}} | no | | 1721 | | Burst/Gap Discard Summary Statistics Block | {{?RFC7004}} | no | | 1722 | | Frame Impairment Statistics Summary | {{?RFC7004}} | no | | 1723 | | Burst/Gap Loss Metrics Block | {{?RFC6958}} | | no | 1724 | | Burst/Gap Discard Metrics Block | {{?RFC7003}} | no | | 1725 | | MPEG2 Transport Stream PSI-Independent Decodability Statistics Metrics Block | {{?RFC6990}} | no | | 1726 | | De-Jitter Buffer Metrics Block | {{?RFC7005}} | no | | 1727 | | Discard Count Metrics Block | {{?RFC7002}} | no | | 1728 | | DRLE (Discard RLE Report) | {{?RFC7097}} | no | | 1729 | | BDR (Bytes Discarded Report) | {{?RFC7243}} | no | | 1730 | | RFISD (RTP Flows Initial Synchronization Delay) | {{?RFC7244}} | no | | 1731 | | RFSO (RTP Flows Synchronization Offset Metrics Block) | {{?RFC7244}} | no | | 1732 | | MOS Metrics Block | {{?RFC7266}} | no | | 1733 | | LCB (Loss Concealment Metrics Block) | {{?RFC7294, Section 4.1}} | no | | 1734 | | CSB (Concealed Seconds Metrics Block) | {{?RFC7294, Section 4.1}} | no | | 1735 | | MPEG2 Transport Stream PSI Decodability Statistics Metrics Block | {{?RFC7380}} | no | | 1736 | | Post-Repair Loss Count Metrics Report Block | {{?RFC7509}} | no | | 1737 | | Video Loss Concealment Metric Report Block | {{?RFC7867}} | no | | 1738 | | Independent Burst/Gap Discard Metrics Block | {{?RFC8015}} | no | | 1739 | {: #tab-xr-blocks title="Extended Report Blocks"} 1740 | 1741 | ## FMT Values for RTP Feedback (RTPFB) Payload Types {#generic-feedback} 1742 | 1743 | The IANA registry for this section is {{IANA-RTCP-FMT-RTPFB-PT}}. 1744 | 1745 | | Name | Long Name | Document | Mappable from QUIC | Comments | 1746 | | -------- | --------- | -------- | ---------------- | -------- | 1747 | | Generic NACK | Generic negative acknowledgement | {{?RFC4585}} | partly | see {{NACK-mappings}} | 1748 | | TMMBR | Temporary Maximum Media Stream Bit Rate Request | {{?RFC5104}} | no | | 1749 | | TMMBN | Temporary Maximum Media Stream Bit Rate Notification | {{?RFC5104}} | no | | 1750 | | RTCP-SR-REQ | RTCP Rapid Resynchronisation Request | {{?RFC6051}} | no | | 1751 | | RAMS | Rapid Acquisition of Multicast Sessions | {{?RFC6285}} | no | | 1752 | | TLLEI | Transport-Layer Third-Party Loss Early Indication | {{?RFC6642}} | no | There is no way to tell a QUIC implementation "don't ask for retransmission". | 1753 | | RTCP-ECN-FB | RTCP ECN Feedback | {{?RFC6679}} | partly | see {{ECN-mappings}} | 1754 | | PAUSE-RESUME | Media Pause/Resume | {{?RFC7728}} | no | | 1755 | | DBI | Delay Budget Information (DBI) | {{3GPP-TS-26.114}} | | 1756 | | CCFB | RTP Congestion Control Feedback | {{?RFC8888}} | QUIC extension needed | see {{CCFB-mappings}} | 1757 | 1758 | ## FMT Values for Payload-Specific Feedback (PSFB) Payload Types {#payload-specific-feedback} 1759 | 1760 | The IANA registry for this section is {{IANA-RTCP-FMT-PSFB-PT}}. 1761 | 1762 | Because QUIC is a generic transport protocol, QUIC feedback cannot replace the 1763 | following Payload-specific RTP Feedback (PSFB) feedback. 1764 | 1765 | | Name | Long Name | Document | 1766 | | -------- | --------- | -------- | 1767 | | PLI | Picture Loss Indication | {{?RFC4585}} | 1768 | | SLI | Slice Loss Indication | {{?RFC4585}} | 1769 | | RPSI | Reference Picture Selection Indication | {{?RFC4585}} | 1770 | | FIR | Full Intra Request Command | {{?RFC5104}} | 1771 | | TSTR | Temporal-Spatial Trade-off Request | {{?RFC5104}} | 1772 | | TSTN | Temporal-Spatial Trade-off Notification | {{?RFC5104}} | 1773 | | VBCM | Video Back Channel Message | {{?RFC5104}} 1774 | | PSLEI | Payload-Specific Third-Party Loss Early Indication | {{?RFC6642}} | 1775 | | ROI | Video region-of-interest (ROI) | {{3GPP-TS-26.114}} | 1776 | | LRR | Layer Refresh Request Command | {{?I-D.draft-ietf-avtext-lrr-07}}| 1777 | | VP | Viewport (VP) | {{3GPP-TS-26.114}} | 1778 | | AFB | Application Layer Feedback | {{?RFC4585}} | 1779 | | TSRR | Temporal-Spatial Resolution Request | {{?I-D.draft-ietf-avtcore-rtcp-green-metadata}} | 1780 | | TSRN | Temporal-Spatial Resolution Notification | {{?I-D.draft-ietf-avtcore-rtcp-green-metadata}} | 1781 | 1782 | ## RTP Header extensions {#rtp-header-extensions} 1783 | 1784 | Like the payload-specific RTCP feedback packets, QUIC cannot directly replace the 1785 | control information in the following header extensions. RoQ does not place 1786 | restrictions on sending any RTP header extensions. However, some extensions, 1787 | such as Transmission Time offsets {{?RFC5450}} are used to improve network 1788 | jitter calculation, which can be done in QUIC if a timestamp extension is used. 1789 | 1790 | ### RTP Compact Header Extensions 1791 | 1792 | The IANA registry for this section is {{IANA-RTP-CHE}}. 1793 | 1794 | | Extension URI | Description | Reference | Mappable from QUIC | 1795 | | ------------- | ----------- | --------- | ---- | 1796 | | urn:ietf:params:rtp-hdrext:toffset | Transmission Time offsets | {{?RFC5450}} | no | 1797 | | urn:ietf:params:rtp-hdrext:ssrc-audio-level | Audio Level | {{?RFC6464}} | no | 1798 | | urn:ietf:params:rtp-hdrext:splicing-interval | Splicing Interval | {{?RFC8286}} | no | 1799 | | urn:ietf:params:rtp-hdrext:smpte-tc | SMPTE time-code mapping | {{?RFC5484}} | no | 1800 | | urn:ietf:params:rtp-hdrext:sdes | Reserved as base URN for RTCP SDES items that are also defined as RTP compact header extensions. | {{?RFC7941}} | no | 1801 | | urn:ietf:params:rtp-hdrext:ntp-64 | Synchronisation metadata: 64-bit timestamp format | {{?RFC6051}} | no | 1802 | | urn:ietf:params:rtp-hdrext:ntp-56 | Synchronisation metadata: 56-bit timestamp format | {{?RFC6051}} | no | 1803 | | urn:ietf:params:rtp-hdrext:encrypt | Encrypted extension header element | {{?RFC6904}} | no | 1804 | | urn:ietf:params:rtp-hdrext:csrc-audio-level | Mixer-to-client audio level indicators | {{?RFC6465}} | no | 1805 | | urn:3gpp:video-orientation:6 | Higher granularity (6-bit) coordination of video orientation (CVO) feature, see clause 6.2.3 | {{3GPP-TS-26.114}} | probably not(?) | 1806 | | urn:3gpp:video-orientation | Coordination of video orientation (CVO) feature, see clause 6.2.3 | {{3GPP-TS-26.114}} | probably not(?) | 1807 | | urn:3gpp:roi-sent | Signalling of the arbitrary region-of-interest (ROI) information for the sent video, see clause 6.2.3.4 | {{3GPP-TS-26.114}} | probably not(?) | 1808 | | urn:3gpp:predefined-roi-sent | Signalling of the predefined region-of-interest (ROI) information for the sent video, see clause 6.2.3.4 | {{3GPP-TS-26.114}} | probably not(?) | 1809 | 1810 | ### RTP SDES Compact Header Extensions 1811 | 1812 | The IANA registry for this section is {{IANA-RTP-SDES-CHE}}. 1813 | 1814 | | Extension URI | Description | Reference | Mappable from QUIC | 1815 | | ------------- | ----------- | --------- | ---- | 1816 | | urn:ietf:params:rtp-hdrext:sdes:cname | Source Description: Canonical End-Point Identifier (SDES CNAME) | {{?RFC7941}} | no | 1817 | | urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id | RTP Stream Identifier | {{?RFC8852}} | no | 1818 | | urn:ietf:params:rtp-hdrext:sdes:repaired-rtp-stream-id | RTP Repaired Stream Identifier | {{?RFC8852}} | no | 1819 | | urn:ietf:params:rtp-hdrext:sdes:CaptId | CLUE CaptId | {{?RFC8849}} | no | 1820 | | urn:ietf:params:rtp-hdrext:sdes:mid | Media identification | {{?RFC9143}} | no | 1821 | 1822 | ## Examples {#rtcp-quic-ext-examples} 1823 | 1824 | ### Mapping QUIC Feedback to RTCP Receiver Reports ("RR") {#RR-mappings} 1825 | 1826 | Considerations for mapping QUIC feedback into *Receiver Reports* (`PT=201`, 1827 | `Name=RR`, {{!RFC3550}}) are: 1828 | 1829 | * *Fraction lost*: When RTP packets are carried in DATAGRAMs, the fraction of lost RTCP packets can be directly inferred from QUIC's acknowledgments. 1830 | The calculation includes all RTP packets up to the acknowledged RTP packet with the highest RTP sequence number. 1831 | * *Cumulative lost*: Similar to the fraction of lost RTP packets, the cumulative 1832 | loss can be inferred from QUIC's acknowledgments, including all packets up 1833 | to the latest acknowledged packet. 1834 | * *Highest Sequence Number received*: In RTCP, this field is a 32-bit field 1835 | that contains the highest sequence number a receiver received in an RTP 1836 | packet and the count of sequence number cycles the receiver has observed. A 1837 | sender sends RTP packets in QUIC packets and receives acknowledgments for 1838 | the QUIC packets. By keeping a mapping from a QUIC packet to the RTP packets 1839 | encapsulated in that QUIC packet, the sender can infer the highest sequence 1840 | number and number of cycles seen by the receiver from QUIC acknowledgments. 1841 | * *Interarrival jitter*: If QUIC acknowledgments carry timestamps as described 1842 | in {{?I-D.draft-smith-quic-receive-ts}}, senders can infer the interarrival 1843 | jitter from the arrival timestamps in QUIC acknowledgments. 1844 | * *Last SR*: Similar to lost RTP packets, the NTP timestamp of the last received 1845 | sender report can be inferred from QUIC acknowledgments. 1846 | * *Delay since last SR*: This field is not required when the receiver reports 1847 | are entirely replaced by QUIC feedback. 1848 | 1849 | ### Congestion Control Feedback ("CCFB") {#CCFB-mappings} 1850 | 1851 | RTP *Congestion Control Feedback* (`PT=205`, `FMT=11`, `Name=CCFB`, 1852 | {{!RFC8888}}) contains acknowledgments, arrival timestamps, and ECN 1853 | notifications for each received RTP packet. Acknowledgments and ECNs can be inferred 1854 | from QUIC as described above. Arrival timestamps can be added through extended 1855 | acknowledgment frames as described in {{?I-D.draft-smith-quic-receive-ts}} or 1856 | {{?I-D.draft-huitema-quic-ts}}. 1857 | 1858 | ### Extended Report ("XR") {#XR-mappings} 1859 | 1860 | *Extended Reports* (`PT=207`, `Name=XR`, {{!RFC3611}}) offer an extensible 1861 | framework for a variety of different control messages. Some of the statistics 1862 | that are defined as extended report blocks can be derived from QUIC, too. Other 1863 | report blocks need to be evaluated individually to determine whether the 1864 | contained information can be transmitted using QUIC instead. {{tab-xr-blocks}} 1865 | in {{extended-reports}} lists considerations for mapping QUIC feedback to some 1866 | of the *Extended Reports*. 1867 | 1868 | ### Application Layer Repair and other Control Messages {#al-repair} 1869 | 1870 | While {{RR-mappings}} presented some RTCP packets that can be replaced by QUIC 1871 | features, QUIC cannot replace all of the defined RTCP packet types. This mostly 1872 | affects RTCP packet types, which carry control information that is to be 1873 | interpreted by the RTP application layer rather than the underlying transport 1874 | protocol itself. 1875 | 1876 | * *Sender Reports* (`PT=200`, `Name=SR`, {{!RFC3550}}) are similar to *Receiver 1877 | Reports*, as described in {{RR-mappings}}. They are sent by media senders and 1878 | additionally contain an NTP and an RTP timestamp and the number of RTP packets and 1879 | octets transmitted by the sender. The timestamps can be used by a receiver to 1880 | synchronize media streams. QUIC cannot provide similar control information since it 1881 | does not know about RTP timestamps. A QUIC receiver cannot calculate the 1882 | packet or octet counts since it does not know about lost DATAGRAMs. Thus, 1883 | sender reports are necessary in RoQ to synchronize media streams at the receiver. 1884 | 1885 | In addition to carrying transmission statistics, RTCP packets can contain 1886 | application layer control information that cannot directly be mapped to QUIC. 1887 | Examples of this information might include: 1888 | 1889 | * *Source Description* (`PT=202`, `Name=SDES`) and *Application* (`PT=204`, 1890 | `Name=APP`) packet types from {{!RFC3550}}, or 1891 | * many of the payload-specific feedback messages (`PT=206`) defined in 1892 | {{!RFC4585}}, used to control the codec behavior of the sender. 1893 | 1894 | Since QUIC does not provide any kind of application layer control messaging, 1895 | QUIC feedback cannot be mapped into these RTCP packet types. If the RTP 1896 | application needs this information, the RTCP packet types are used in the same 1897 | way as they would be used over any other transport protocol. 1898 | 1899 | # Header overhead considerations {#overhead-estimation} 1900 | 1901 | As discussed in {{RTCP-considerations}}, the header overhead of an RTP packet 1902 | sent over RoQ cannot easily be determined. This section gives an estimation of the 1903 | minimum and maximum header overhead of different combinations of STREAM and 1904 | DATAGRAM frames using either IPv4 or IPv6. However, even this estimation is not 1905 | exactly correct, since it does not take into account additional complications such as that RTP packets may be 1906 | fragmented over multiple STREAM frames and that QUIC packets may contain more 1907 | than a single FRAME, so that the RTCP overhead could thus be the shared overhead of 1908 | multiple RTP packets being sent in different QUIC frames in the same QUIC 1909 | packet. 1910 | 1911 | * At least 20 Bytes (v4) or 40 Bytes (v6) IP header 1912 | * 8 Bytes UDP header 1913 | * 2-25 Bytes QUIC Short header packets 1914 | * 1 Byte fixed header 1915 | * 0-20 Bytes Connection ID 1916 | * 1-4 Bytes Packet Number 1917 | * 2-25 Bytes STREAM frame header 1918 | * 1 Byte type 1919 | * 1-8 Bytes stream ID 1920 | * Optional 1-8 Bytes Offset 1921 | * Optional 1-8 Bytes Length 1922 | * 1-9 Bytes DATAGRAM frame header 1923 | * 1 Byte type 1924 | * Optional 1-8 Bytes length 1925 | * 1-8 Bytes RoQ Flow ID 1926 | 1927 | * IPv4 with STREAM frames 1928 | * Minimum: 20+8+2+2+1=33 Bytes 1929 | * Maximum: 20+8+25+25+8=86 Bytes 1930 | * IPv6 with STREAM frames 1931 | * Minimum: 40+8+2+2+1=53 Bytes 1932 | * Maximum: 40+8+25+25+8=106 Bytes 1933 | * IPv4 with DATAGRAM frames 1934 | * Minimum: 20+8+2+1+1=32 Bytes 1935 | * Maximum: 20+8+25+9+8=70 Bytes 1936 | * IPv6 with DATAGRAM frames 1937 | * Minimum: 40+8+2+1+1=52 Bytes 1938 | * Maximum: 40+8+25+9+8=90 Bytes 1939 | 1940 | 1941 | # Acknowledgments 1942 | {:numbered="false"} 1943 | 1944 | Early versions of this document were similar in spirit to 1945 | {{?I-D.draft-hurst-quic-rtp-tunnelling}}, although many details differ. The 1946 | authors would like to thank Sam Hurst for providing his thoughts about how QUIC 1947 | could be used to carry RTP. 1948 | 1949 | The guidance in {{quic-streams}} about configuring the number of parallel unidirectional QUIC streams is based on {{Section 6.2 of ?RFC9114}}, with obvious substitutions for RTP. 1950 | 1951 | The authors would like to thank Bernard Aboba, David Schinazi, Gurtej Singh Chandok, Lucas Pardue, Nils Ohlmeier, Sam Hurst, Sergio Garcia Murillo, and Vidhi Goel for their valuable comments and suggestions contributing to this document. 1952 | 1953 | The authors would also like to thank Sam Hurst and Lorenzo Miniero for 1954 | implementing RTP over QUIC. 1955 | --------------------------------------------------------------------------------