< draft-pardue-quic-http-mcast-03.txt   draft-pardue-quic-http-mcast-04.txt >
Network Working Group L. Pardue Network Working Group L. Pardue
Internet-Draft R. Bradbury Internet-Draft
Intended status: Informational BBC Research & Development Intended status: Informational R. Bradbury
Expires: February 7, 2019 August 6, 2018 Expires: August 9, 2019 S. Hurst
BBC Research & Development
February 5, 2019
Hypertext Transfer Protocol (HTTP) over multicast QUIC Hypertext Transfer Protocol (HTTP) over multicast QUIC
draft-pardue-quic-http-mcast-03 draft-pardue-quic-http-mcast-04
Abstract Abstract
This document specifies a profile of the QUIC protocol and the HTTP/ This document specifies a profile of the QUIC protocol and the HTTP/3
QUIC mapping that facilitates the transfer of HTTP resources over mapping that facilitates the transfer of HTTP resources over
multicast IP using the QUIC transport as its framing and multicast IP using the QUIC transport as its framing and
packetisation layer. Compatibility with the QUIC protocol's syntax packetisation layer. Compatibility with the QUIC protocol's syntax
and semantics is maintained as far as practical and additional and semantics is maintained as far as practical and additional
features are specified where this is not possible. features are specified where this is not possible.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 7, 2019. This Internet-Draft will expire on August 9, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Notational Conventions . . . . . . . . . . . . . . . . . 6 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 6
1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 6 1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 6
2. Multicast QUIC Sessions . . . . . . . . . . . . . . . . . . . 7 2. Multicast QUIC Sessions . . . . . . . . . . . . . . . . . . . 7
2.1. Session States . . . . . . . . . . . . . . . . . . . . . 7 2.1. Session States . . . . . . . . . . . . . . . . . . . . . 8
2.1.1. Session Establishment . . . . . . . . . . . . . . . . 8 2.1.1. Session Establishment . . . . . . . . . . . . . . . . 8
2.1.2. Session Termination . . . . . . . . . . . . . . . . . 8 2.1.2. Session Termination . . . . . . . . . . . . . . . . . 9
2.1.3. Session Migration . . . . . . . . . . . . . . . . . . 9 2.1.3. Session Migration . . . . . . . . . . . . . . . . . . 9
2.2. Session Parameters . . . . . . . . . . . . . . . . . . . 9 2.2. Session Parameters . . . . . . . . . . . . . . . . . . . 9
2.3. Session Identification . . . . . . . . . . . . . . . . . 10 2.3. Session Identification . . . . . . . . . . . . . . . . . 10
2.4. Session Security . . . . . . . . . . . . . . . . . . . . 10 2.4. Session Security . . . . . . . . . . . . . . . . . . . . 11
3. Session Advertisement . . . . . . . . . . . . . . . . . . . . 11 3. Session Advertisement . . . . . . . . . . . . . . . . . . . . 11
3.1. Version Advertisement . . . . . . . . . . . . . . . . . . 11 3.1. Version Advertisement . . . . . . . . . . . . . . . . . . 12
3.2. Security Context . . . . . . . . . . . . . . . . . . . . 12 3.2. Security Context . . . . . . . . . . . . . . . . . . . . 13
3.2.1. Cipher Suite . . . . . . . . . . . . . . . . . . . . 12 3.2.1. Cipher Suite . . . . . . . . . . . . . . . . . . . . 13
3.2.2. Key Exchange . . . . . . . . . . . . . . . . . . . . 13 3.2.2. Key Exchange . . . . . . . . . . . . . . . . . . . . 13
3.2.3. Initialization Vector . . . . . . . . . . . . . . . . 13 3.2.3. Initialization Vector . . . . . . . . . . . . . . . . 13
3.3. Session Identification . . . . . . . . . . . . . . . . . 13 3.3. Session Identification . . . . . . . . . . . . . . . . . 14
3.4. Session Idle Timeout . . . . . . . . . . . . . . . . . . 13 3.4. Session Idle Timeout . . . . . . . . . . . . . . . . . . 14
3.5. Session Peak Flow Rate . . . . . . . . . . . . . . . . . 14 3.5. Session Peak Flow Rate . . . . . . . . . . . . . . . . . 15
3.6. Resource Concurrency . . . . . . . . . . . . . . . . . . 14 3.6. Resource Concurrency . . . . . . . . . . . . . . . . . . 15
3.7. Additional TransportParameter Considerations . . . . . . 15 3.7. Additional TransportParameter Considerations . . . . . . 16
3.8. Digest Algorithm . . . . . . . . . . . . . . . . . . . . 15 3.8. Digest Algorithm . . . . . . . . . . . . . . . . . . . . 16
3.9. Signature Algorithm . . . . . . . . . . . . . . . . . . . 16 3.9. Signature Algorithm . . . . . . . . . . . . . . . . . . . 17
4. QUIC Profile . . . . . . . . . . . . . . . . . . . . . . . . 17 4. QUIC Profile . . . . . . . . . . . . . . . . . . . . . . . . 18
4.1. Packet Size . . . . . . . . . . . . . . . . . . . . . . . 17 4.1. Packet Size . . . . . . . . . . . . . . . . . . . . . . . 18
4.2. Packet Format . . . . . . . . . . . . . . . . . . . . . . 17 4.2. Packet Format . . . . . . . . . . . . . . . . . . . . . . 18
4.3. Connection Identifier . . . . . . . . . . . . . . . . . . 18 4.2.1. Packet Numbers . . . . . . . . . . . . . . . . . . . 18
4.4. Stream Identifier . . . . . . . . . . . . . . . . . . . . 18 4.2.2. Spin Bit . . . . . . . . . . . . . . . . . . . . . . 19
4.5. Flow Control . . . . . . . . . . . . . . . . . . . . . . 18 4.3. Connection Identifier . . . . . . . . . . . . . . . . . . 19
4.6. Stream Termination . . . . . . . . . . . . . . . . . . . 18 4.4. Stream Identifier . . . . . . . . . . . . . . . . . . . . 19
4.7. Session Shutdown . . . . . . . . . . . . . . . . . . . . 19 4.5. Flow Control . . . . . . . . . . . . . . . . . . . . . . 19
4.8. Session Keep-alive . . . . . . . . . . . . . . . . . . . 19 4.6. Stream Termination . . . . . . . . . . . . . . . . . . . 20
4.9. Loss Detection and Recovery . . . . . . . . . . . . . . . 19 4.7. Session Shutdown . . . . . . . . . . . . . . . . . . . . 20
4.10. Prohibited QUIC Frames and Packets . . . . . . . . . . . 20 4.8. Connection Migration . . . . . . . . . . . . . . . . . . 20
5. HTTP/QUIC Profile . . . . . . . . . . . . . . . . . . . . . . 20 4.9. Explicit Congestion Notification . . . . . . . . . . . . 21
5.1. HTTP Connection Settings . . . . . . . . . . . . . . . . 20 4.10. Session Keep-alive . . . . . . . . . . . . . . . . . . . 21
5.2. Server Push . . . . . . . . . . . . . . . . . . . . . . . 21 4.11. Loss Detection and Recovery . . . . . . . . . . . . . . . 21
5.3. Metadata Compression . . . . . . . . . . . . . . . . . . 21 4.12. Prohibited QUIC Frames and Packets . . . . . . . . . . . 21
5.4. Prioritisation . . . . . . . . . . . . . . . . . . . . . 22 5. HTTP/3 Profile . . . . . . . . . . . . . . . . . . . . . . . 22
5.5. Session Tear-down . . . . . . . . . . . . . . . . . . . . 22 5.1. HTTP Connection Settings . . . . . . . . . . . . . . . . 22
5.6. HTTP/QUIC Extension frames . . . . . . . . . . . . . . . 22 5.2. Server Push . . . . . . . . . . . . . . . . . . . . . . . 22
5.7. Prohibited HTTP/QUIC Frames . . . . . . . . . . . . . . . 22 5.3. Metadata Compression . . . . . . . . . . . . . . . . . . 23
5.4. Prioritisation . . . . . . . . . . . . . . . . . . . . . 24
6. Application-Layer Security . . . . . . . . . . . . . . . . . 23 5.5. Session Tear-down . . . . . . . . . . . . . . . . . . . . 24
6.1. Content Integrity . . . . . . . . . . . . . . . . . . . . 23 5.6. HTTP/3 Extension frames . . . . . . . . . . . . . . . . . 24
6.2. Content Authenticity . . . . . . . . . . . . . . . . . . 23 5.7. Prohibited HTTP/3 Frames . . . . . . . . . . . . . . . . 24
6.3. Content Confidentiality . . . . . . . . . . . . . . . . . 25 6. Application-Layer Security . . . . . . . . . . . . . . . . . 24
7. Loss Recovery . . . . . . . . . . . . . . . . . . . . . . . . 25 6.1. Content Integrity . . . . . . . . . . . . . . . . . . . . 25
7.1. Forward Error Correction . . . . . . . . . . . . . . . . 25 6.2. Content Authenticity . . . . . . . . . . . . . . . . . . 25
7.2. Unicast Repair . . . . . . . . . . . . . . . . . . . . . 25 6.3. Content Confidentiality . . . . . . . . . . . . . . . . . 26
8. Transmission of Partial Content . . . . . . . . . . . . . . . 26 7. Loss Recovery . . . . . . . . . . . . . . . . . . . . . . . . 27
9. Protocol Identifier . . . . . . . . . . . . . . . . . . . . . 26 7.1. Forward Error Correction . . . . . . . . . . . . . . . . 27
9.1. Draft Version Identification . . . . . . . . . . . . . . 26 7.2. Unicast Repair . . . . . . . . . . . . . . . . . . . . . 27
10. Discovery of Multicast QUIC Sessions . . . . . . . . . . . . 27 8. Transmission of Partial Content . . . . . . . . . . . . . . . 28
10.1. Source-specific Multicast Advertisement . . . . . . . . 28 9. Protocol Identifier . . . . . . . . . . . . . . . . . . . . . 28
10.2. Session Parameter Advertisement . . . . . . . . . . . . 28 9.1. Draft Version Identification . . . . . . . . . . . . . . 28
10.2.1. Version . . . . . . . . . . . . . . . . . . . . . . 28 10. Discovery of Multicast QUIC Sessions . . . . . . . . . . . . 29
10.2.2. Cipher Suite . . . . . . . . . . . . . . . . . . . . 28 10.1. Source-specific Multicast Advertisement . . . . . . . . 29
10.2.3. Session Key . . . . . . . . . . . . . . . . . . . . 29 10.2. Session Parameter Advertisement . . . . . . . . . . . . 30
10.2.4. Session Cipher Initialization Vector . . . . . . . . 29 10.2.1. Version . . . . . . . . . . . . . . . . . . . . . . 30
10.2.5. Session Identification . . . . . . . . . . . . . . . 29 10.2.2. Cipher Suite . . . . . . . . . . . . . . . . . . . . 30
10.2.6. Session Idle Timeout Period . . . . . . . . . . . . 30 10.2.3. Session Key . . . . . . . . . . . . . . . . . . . . 31
10.2.7. Resource Concurrency . . . . . . . . . . . . . . . . 30 10.2.4. Session Cipher Initialization Vector . . . . . . . . 31
10.2.8. Session Peak Flow Rate . . . . . . . . . . . . . . . 30 10.2.5. Session Identification . . . . . . . . . . . . . . . 31
10.2.9. Digest Algorithm . . . . . . . . . . . . . . . . . . 31 10.2.6. Session Idle Timeout Period . . . . . . . . . . . . 32
10.2.10. Signature Algorithm . . . . . . . . . . . . . . . . 31 10.2.7. Resource Concurrency . . . . . . . . . . . . . . . . 32
11. Security and Privacy Considerations . . . . . . . . . . . . . 32 10.2.8. Session Peak Flow Rate . . . . . . . . . . . . . . . 32
11.1. Pervasive Monitoring . . . . . . . . . . . . . . . . . . 32 10.2.9. Digest Algorithm . . . . . . . . . . . . . . . . . . 33
11.1.1. Large-scale Data Gathering and Correlation . . . . . 32 10.2.10. Signature Algorithm . . . . . . . . . . . . . . . . 33
11.1.2. Changing Content . . . . . . . . . . . . . . . . . . 33 11. Security and Privacy Considerations . . . . . . . . . . . . . 34
11.2. Protection of Discovery Mechanism . . . . . . . . . . . 33 11.1. Pervasive Monitoring . . . . . . . . . . . . . . . . . . 34
11.3. Spoofing . . . . . . . . . . . . . . . . . . . . . . . . 33 11.1.1. Large-scale Data Gathering and Correlation . . . . . 34
11.3.1. Spoofed Ack Attacks . . . . . . . . . . . . . . . . 33 11.1.2. Changing Content . . . . . . . . . . . . . . . . . . 35
11.3.2. Sender Spoofing . . . . . . . . . . . . . . . . . . 33 11.2. Protection of Discovery Mechanism . . . . . . . . . . . 35
11.3.3. Receiver Spoofing . . . . . . . . . . . . . . . . . 34 11.3. Spoofing . . . . . . . . . . . . . . . . . . . . . . . . 35
11.4. Replay Attacks . . . . . . . . . . . . . . . . . . . . . 34 11.3.1. Spoofed Ack Attacks . . . . . . . . . . . . . . . . 35
11.5. Message Deletion . . . . . . . . . . . . . . . . . . . . 34 11.3.2. Sender Spoofing . . . . . . . . . . . . . . . . . . 35
11.6. Denial of Service . . . . . . . . . . . . . . . . . . . 34 11.3.3. Receiver Spoofing . . . . . . . . . . . . . . . . . 36
11.6.1. Unprotected Frames and Packets . . . . . . . . . . . 35 11.4. Replay Attacks . . . . . . . . . . . . . . . . . . . . . 36
11.6.2. Network Performance Degradation . . . . . . . . . . 35 11.5. Message Deletion . . . . . . . . . . . . . . . . . . . . 36
11.6.3. Unicast Repair Stampeding Herd . . . . . . . . . . . 35 11.6. Denial of Service . . . . . . . . . . . . . . . . . . . 36
11.7. Receiver Resource Usage . . . . . . . . . . . . . . . . 35 11.6.1. Unprotected Frames and Packets . . . . . . . . . . . 37
11.8. Unicast Repair Information Leakage . . . . . . . . . . . 35 11.6.2. Network Performance Degradation . . . . . . . . . . 37
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 11.6.3. Unicast Repair Stampeding Herd . . . . . . . . . . . 37
12.1. Registration of Protocol Identification String . . . . . 36 11.7. Receiver Resource Usage . . . . . . . . . . . . . . . . 37
12.2. Registration of Alt-Svc parameters . . . . . . . . . . . 36 11.8. Unicast Repair Information Leakage . . . . . . . . . . . 37
12.2.1. Source Address . . . . . . . . . . . . . . . . . . . 37 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38
12.2.2. Cipher Suite . . . . . . . . . . . . . . . . . . . . 37 12.1. Registration of Protocol Identification String . . . . . 38
12.2.3. Key . . . . . . . . . . . . . . . . . . . . . . . . 37 12.2. Registration of Alt-Svc parameters . . . . . . . . . . . 38
12.2.4. Initialization Vector . . . . . . . . . . . . . . . 37 12.2.1. Source Address . . . . . . . . . . . . . . . . . . . 39
12.2.5. Session Identifier . . . . . . . . . . . . . . . . . 37 12.2.2. Cipher Suite . . . . . . . . . . . . . . . . . . . . 39
12.2.6. Session Idle Timeout . . . . . . . . . . . . . . . . 37 12.2.3. Key . . . . . . . . . . . . . . . . . . . . . . . . 39
12.2.7. Maximum Concurrent Resources . . . . . . . . . . . . 37 12.2.4. Initialization Vector . . . . . . . . . . . . . . . 39
12.2.8. Peak Flow Rate . . . . . . . . . . . . . . . . . . . 38 12.2.5. Session Identifier . . . . . . . . . . . . . . . . . 39
12.2.9. Digest Algorithm . . . . . . . . . . . . . . . . . . 38 12.2.6. Session Idle Timeout . . . . . . . . . . . . . . . . 39
12.2.10. Signature Algorithm . . . . . . . . . . . . . . . . 38 12.2.7. Maximum Concurrent Resources . . . . . . . . . . . . 39
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 38 12.2.8. Peak Flow Rate . . . . . . . . . . . . . . . . . . . 40
13.1. Normative References . . . . . . . . . . . . . . . . . . 38 12.2.9. Digest Algorithm . . . . . . . . . . . . . . . . . . 40
13.2. Informative References . . . . . . . . . . . . . . . . . 39 12.2.10. Signature Algorithm . . . . . . . . . . . . . . . . 40
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 41 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 40
Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 42 13.1. Normative References . . . . . . . . . . . . . . . . . . 40
B.1. Session Advertisement . . . . . . . . . . . . . . . . . . 42 13.2. Informative References . . . . . . . . . . . . . . . . . 42
B.1.1. Source-specific Multicast QUIC Session . . . . . . . 42 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 44
Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 44
B.1. Session Advertisement . . . . . . . . . . . . . . . . . . 44
B.1.1. Source-specific Multicast QUIC Session . . . . . . . 44
B.1.2. Source-specific Multicast QUIC Session with Transport B.1.2. Source-specific Multicast QUIC Session with Transport
Encryption using a Symmetric Key . . . . . . . . . . 42 Encryption using a Symmetric Key . . . . . . . . . . 44
B.1.3. Source-specific Multicast QUIC Session with Transport B.1.3. Source-specific Multicast QUIC Session with Transport
Encryption, Content Integrity and Authenticity . . . 43 Encryption, Content Integrity and Authenticity . . . 45
B.2. Resource Transfer . . . . . . . . . . . . . . . . . . . . 43 B.2. Resource Transfer . . . . . . . . . . . . . . . . . . . . 45
B.2.1. Transfer without Content Integrity or Authenticity . 43 B.2.1. Transfer without Content Integrity or Authenticity . 46
B.2.2. Transfer of Partial Content without Content Integrity B.2.2. Transfer of Partial Content without Content Integrity
or Authenticity . . . . . . . . . . . . . . . . . . . 44 or Authenticity . . . . . . . . . . . . . . . . . . . 46
B.2.3. Transfer with Content Integrity and without B.2.3. Transfer with Content Integrity and without
Authenticity . . . . . . . . . . . . . . . . . . . . 44 Authenticity . . . . . . . . . . . . . . . . . . . . 47
B.2.4. Partial Transfer with Content Integrity and without B.2.4. Partial Transfer with Content Integrity and without
Authenticity . . . . . . . . . . . . . . . . . . . . 45 Authenticity . . . . . . . . . . . . . . . . . . . . 47
B.2.5. Transfer with Content Integrity and Authenticity . . 45 B.2.5. Transfer with Content Integrity and Authenticity . . 48
B.2.6. Partial Transfer with Content Integrity and B.2.6. Partial Transfer with Content Integrity and
Authenticity . . . . . . . . . . . . . . . . . . . . 46 Authenticity . . . . . . . . . . . . . . . . . . . . 49
Appendix C. Summary of differences from unicast QUIC and Appendix C. Summary of differences from unicast QUIC and HTTP/3 50
HTTP/QUIC . . . . . . . . . . . . . . . . . . . . . 47 Appendix D. Changelog . . . . . . . . . . . . . . . . . . . . . 60
Appendix D. Changelog . . . . . . . . . . . . . . . . . . . . . 54 D.1. Since draft-pardue-quic-http-mcast-03 . . . . . . . . . . 60
D.1. Since draft-pardue-quic-http-mcast-02 . . . . . . . . . . 54 D.2. Since draft-pardue-quic-http-mcast-02 . . . . . . . . . . 60
D.2. Since draft-pardue-quic-http-mcast-01 . . . . . . . . . . 54 D.3. Since draft-pardue-quic-http-mcast-01 . . . . . . . . . . 60
D.3. Since draft-pardue-quic-http-mcast-00 . . . . . . . . . . 55 D.4. Since draft-pardue-quic-http-mcast-00 . . . . . . . . . . 61
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 55 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 61
1. Introduction 1. Introduction
The means to bulk transfer resources over multicast IP [RFC1112] The means to bulk transfer resources over multicast IP [RFC1112]
using HTTP semantics presents an opportunity to more efficiently using HTTP semantics presents an opportunity to more efficiently
deliver services at scale, while leveraging the wealth of existing deliver services at scale, while leveraging the wealth of existing
HTTP-related standards, tools and applications. Audio-visual HTTP-related standards, tools and applications. Audio-visual
segmented media, in particular, would benefit from this mode of segmented media, in particular, would benefit from this mode of
transmission. transmission.
The carriage of HTTP over multicast IP may be satisfied using The carriage of HTTP over multicast IP may be satisfied using
existing technologies, for example the Real-time Transport Protocol existing technologies, for example the Real-time Transport Protocol
(RTP) [RFC3550]. However, such protocols typically require the (RTP) [RFC3550], File Delivery over Unidirectional Transport (FLUTE)
translation or encapsulation of HTTP. This introduces concerns for [RFC6726], and NACK-Oriented Reliable Multicast (NORM) [RFC5740].
providers of services, such as defining the translation, additional However, such protocols typically require the translation or
workload, complication of workflows, manageability issues, versioning encapsulation of HTTP. This introduces concerns for providers of
issues, and so on. services, such as defining the translation, additional workload,
complication of workflows, manageability issues, versioning issues,
and so on.
In contrast, this document describes a simpler and more direct In contrast, this document describes a simpler and more direct
expression of HTTP semantics over multicast IP. HTTP over multicast expression of HTTP semantics over multicast IP. HTTP over multicast
QUIC is a profile of the QUIC protocol [QUIC-TRANSPORT] (Section 4) QUIC is a profile of the QUIC protocol [QUIC-TRANSPORT] (Section 4)
and the HTTP/QUIC mapping [QUIC-HTTP] (Section 5). This includes the and the HTTP/3 mapping [QUIC-HTTP] (Section 5). This includes the
repurposing of certain QUIC packet fields and changes to some repurposing of certain QUIC packet fields and changes to some
protocol procedures (e.g. prohibition of the usage of certain frame protocol procedures (e.g. prohibition of the usage of certain frame
types) which, in turn, change the behavioural expectations of types) which, in turn, change the behavioural expectations of
endpoints. However, the profile purposely limits the scope of change endpoints. However, the profile purposely limits the scope of change
in order to preserve maximum compatibility with conventional QUIC. in order to preserve maximum syntactic and semantic compatibility
For the reader's convenience, the differences between this with conventional QUIC. For the reader's convenience, the
specification and conventional QUIC are summarised in Appendix C. differences between this specification and conventional QUIC are
summarised in Appendix C.
This profile prohibits the transmission of QUIC packets from receiver This profile prohibits the transmission of QUIC packets from receiver
to sender via multicast IP. The use of side-channel or out-of-band to sender via multicast IP. The use of side-channel or out-of-band
feedback mechanisms is not prohibited by this specification, but is feedback mechanisms is not prohibited by this specification, but is
out of scope and these are not considered further by the present out of scope and these are not considered further by the present
document. document.
Experience indicates that a generally available multicast deployment Experience indicates that a generally available multicast deployment
is difficult to achieve on the Internet notwithstanding the is difficult to achieve on the Internet notwithstanding the
improvements that IPv6 [RFC2460] makes in this area. There is improvements that IPv6 [RFC2460] makes in this area. There is
skipping to change at page 7, line 7 skipping to change at page 7, line 13
this specification. this specification.
o session: See multicast QUIC session. o session: See multicast QUIC session.
o session ID: The identifier for a multicast QUIC session. o session ID: The identifier for a multicast QUIC session.
o session parameter: Characteristic of a multicast QUIC session. o session parameter: Characteristic of a multicast QUIC session.
2. Multicast QUIC Sessions 2. Multicast QUIC Sessions
An HTTP/QUIC connection [QUIC-TRANSPORT] carried over bidirectional A QUIC connection [QUIC-TRANSPORT] carried over bidirectional unicast
unicast is defined as a conversation between two QUIC endpoints that is defined as a conversation between two QUIC endpoints that
multiplexes several logical streams within a single encryption multiplexes several logical streams within a single encryption
context. This is a one-to-one relationship. Furthermore, QUIC context. This is a one-to-one relationship. Furthermore, QUIC
connections achieve decoupling from the underlying network (IP and connections achieve decoupling from the underlying network (IP and
port) by means of a Connection ID. Use of a consistent connection port) by means of a pair of Connection IDs, each uniquely identifying
identifier allows QUIC connections to survive changes to the network the flow in one direction. Use of a consistent connection identifier
allows QUIC connections to survive changes to the network
connectivity. The establishment of a QUIC connection relies upon an connectivity. The establishment of a QUIC connection relies upon an
up-front, in-band exchange (and possible negotiation) of up-front, in-band exchange (and possible negotiation) of
cryptographic and transport parameters (conveyed in QUIC handshake cryptographic and transport parameters (conveyed in QUIC handshake
messages) and HTTP-specific settings (conveyed in HTTP/QUIC messages).
The mapping of HTTP semantics over the QUIC transport protocol
[QUIC-HTTP] facilitates the transfer of hypermedia over QUIC
connections. The establishment of a HTTP/3 connection relies upon
all the requirements stipulated for the transport, as well as
communication of HTTP-specific settings (conveyed in HTTP/3
"SETTINGS" frames). Such parameters may be required or optional and "SETTINGS" frames). Such parameters may be required or optional and
may be used by either endpoint to control the characteristics of may be used by either endpoint to control the characteristics of
connection usage. connection usage.
This concept of a connection does not suit the carriage of HTTP/QUIC This concept of a connection does not suit the carriage of HTTP/3
over unidirectional network associations such as multicast IP. In over unidirectional network associations such as multicast IP. In
fact, there is no requirement for either endpoint (multicast sender fact, there is no requirement for either endpoint (multicast sender
or receiver) to be in existence in order for the other to start or or receiver) to be in existence in order for the other to start or
join this one-sided conversation. The term "connection" is join this one-sided conversation. The term "connection" is
misleading in this context; therefore we introduce an alternative misleading in this context; therefore we introduce an alternative
term "multicast QUIC session" or simply "session", which is defined term "multicast QUIC session" or simply "session", which is defined
as the logical entity describing the characteristics of the as the logical entity describing the characteristics of the
anticipated unidirectional flow of metadata and data. Such anticipated unidirectional flow of metadata and data. Such
characteristics are expressed as "session parameters", described in characteristics are expressed as "session parameters", described in
Section 2.2. Advertisement of multicast QUIC sessions, specified in Section 2.2. Advertisement of multicast QUIC sessions, specified in
skipping to change at page 10, line 13 skipping to change at page 10, line 28
achieved using HTTP Alternative Services [RFC7838] and is explained achieved using HTTP Alternative Services [RFC7838] and is explained
in Section 3. Other advertisement solutions are not prohibited but in Section 3. Other advertisement solutions are not prohibited but
are not explored in this document. are not explored in this document.
Session parameters MUST NOT change during the lifetime of a session. Session parameters MUST NOT change during the lifetime of a session.
This restriction also applies to HTTP-level settings (see This restriction also applies to HTTP-level settings (see
Section 5.1). Section 5.1).
2.3. Session Identification 2.3. Session Identification
This document defines a 64-bit session identifier used to identify a This document defines an optional session identifier used to identify
session. This "Session ID" affords independence from multicast IP, a session. This "Session ID" affords independence from multicast IP,
creating the possibility for a session to span multiple multicast creating the possibility for a session to span multiple multicast
groups, or to migrate a session to a different multicast group. groups, or to migrate a session to a different multicast group.
Assignment of Session ID is considered out of this document's scope. Assignment of Session ID is considered out of this document's scope.
The Session ID is carried in the Connection ID field of the QUIC The Session ID is carried in the Destination Connection ID field of
packet (see Section 4.3). the QUIC packet (see Section 4.3). Source Connection IDs are not
used.
A multicast sender participating in a session MUST send QUIC packets The maximum size of a Session ID is 144 bits. The size of the
with a matching Session ID. A multicast receiver participating in a Destination Connection ID field used to convey the Session ID SHALL
session MUST validate that the Session ID of received QUIC packets be the smallest number of full bytes required to represent the full
matches that advertised in the session parameters (Section 3, Session ID value advertised in the "session-id" session parameter
Section 10.2) before any HTTP-level processing is done. In the case (Section 10.2.5). If no "session-id" parameter is advertised, then
of validation failure, the receiver SHOULD ignore the packet in order this session has no explicit session ID, and the Destination
to protect itself from denial-of-service attacks. Connection ID field SHALL be omitted from all QUIC packets related to
the session.
A multicast sender participating in a session with an advertised
"session-id" session parameter MUST send QUIC packets with a matching
Session ID. Conversely, a multicast sender participating in a
session without an advertised "session-id" session parameter MUST NOT
send QUIC packets with a Destination Connection ID field.
A multicast receiver participating in a session with an advertised
"session-id" session parameter MUST validate that the Session ID of
received QUIC packets matches that advertised in the session
parameters (Section 10.2.5) before any HTTP-level processing is done.
In the case of validation failure, the receiver SHOULD ignore the
packet in order to protect itself from denial-of-service attacks.
2.4. Session Security 2.4. Session Security
*Authors' Note:* Security handshake (as described in WG documents) *Authors' Note:* Security handshake (as described in WG documents)
is in flux. This section will track developments and will be is in flux. This section will track developments and will be
updated accordingly. updated accordingly.
The QUIC cryptographic handshake ([QUIC-TRANSPORT] and [QUIC-TLS]) The QUIC cryptographic handshake ([QUIC-TRANSPORT] and [QUIC-TLS])
sets out methods to achieve the goals of authenticated key exchange sets out methods to achieve the goals of authenticated key exchange
and QUIC packet protection between two endpoints forming a QUIC and QUIC packet protection between two endpoints forming a QUIC
connection. The design facilitates low-latency connection; 1-RTT or connection. The design facilitates low-latency connection; 1-RTT or
0-RTT. QUIC Stream 0 is reserved for handshake messages. 0-RTT. This specification replaces the in-band security handshake,
achieving similar goals through the use of session parameters
This specification replaces the in-band security handshake, achieving described in Section 3.2.
similar goals through the use of session parameters described in
Section 3.2. For the purpose of compatibility, the use of QUIC
stream 0 (see Section 4.4) is reserved.
Integrity and authenticity concerns are addressed in Section 6.1 and Integrity and authenticity concerns are addressed in Section 6.1 and
Section 6.2 respectively. In order to protect themselves from attack Section 6.2 respectively. In order to protect themselves from attack
vectors, endpoints SHOULD NOT participate in sessions for which they vectors, endpoints SHOULD NOT participate in sessions for which they
cannot establish reasonable confidence over the cipher suite or key cannot establish reasonable confidence over the cipher suite or key
in use for that session. Participants MAY leave any session that in use for that session. Participants MAY leave any session that
fails to successfully match anticipated security characteristics. fails to successfully match anticipated security characteristics.
3. Session Advertisement 3. Session Advertisement
skipping to change at page 13, line 29 skipping to change at page 14, line 11
parameter, which is advertised as the Alt-Svc parameter "iv" parameter, which is advertised as the Alt-Svc parameter "iv"
(Section 10.2.4). The parameter carries a variable-length hex- (Section 10.2.4). The parameter carries a variable-length hex-
encoded IV for use with the session cipher suite and key. encoded IV for use with the session cipher suite and key.
The Alt-Svc "iv" parameter is OPTIONAL. Session advertisments that The Alt-Svc "iv" parameter is OPTIONAL. Session advertisments that
omit this parameter imply that the IV may be available via an out-of- omit this parameter imply that the IV may be available via an out-of-
band method not described in this document. band method not described in this document.
3.3. Session Identification 3.3. Session Identification
[QUIC-TRANSPORT] specifies how the QUIC Connection ID is used, in [QUIC-TRANSPORT] specifies how the QUIC connection identifiers are
particular the client-side generation of this value. In a used, in particular the independent selection of these identfiers by
unidirectional multicast environment, there is no meaningful way for each endpoint for its peer. In a unidirectional multicast
a client to generate a Connection ID and use it. This document environment, there is no meaningful way for an endpoint to generate a
defines a "session identifier" session parameter, which is advertised connection identifier for its peer to use. This document defines a
as the Alt-Svc parameter "session-id" (Section 10.2.5). The "session identifier" session parameter, which is advertised as the
requirements for the usage of session identifiers have already been Alt-Svc parameter "session-id" (Section 10.2.5). The requirements
described in Section 2.3. for the usage of session identifiers have already been described in
Section 2.3.
The Alt-Svc "session-id" parameter is mandatory. Session The Alt-Svc "session-id" parameter is optional. Session
advertisments MUST contain at least one instance. It MAY be repeated advertisements MAY contain zero or more instances. The parameter MAY
with different values, indicating that multiple sessions are present. be repeated with different values, indicating that multiple sessions
are multiplexed in the same multicast group.
*Authors' Note:* We invite review comments on mandating a single *Authors' Note:* We invite review comments on mandating a single
session identifier per advertised session, i.e. only one session session identifier per advertised session, i.e. only one session
identifier per ASM {G} or SSM {S,G}. identifier per ASM {G} or SSM {S,G}.
3.4. Session Idle Timeout 3.4. Session Idle Timeout
Conventional QUIC connections may be implicitly terminated following Conventional QUIC connections may be implicitly terminated following
a period of idleness (lack of network activity). The required QUIC a period of idleness (lack of network activity). The optional QUIC
TransportParameter "idle_timeout" provides a means for endpoints to TransportParameter "idle_timeout" provides a means for endpoints to
specify the timeout period. This document defines a "session idle specify the timeout period. This document defines a "session idle
timeout" session parameter, which is advertised as the Alt-Svc timeout" session parameter, which is advertised as the Alt-Svc
parameter "session-idle-timeout" (Section 10.2.6). This session parameter "session-idle-timeout" (Section 10.2.6). This session
parameter mimics the behaviour of "idle_timeout", providing a means parameter mimics the behaviour of "idle_timeout", providing a means
for multicast QUIC sessions to define their own idle timeout periods. for multicast QUIC sessions to define their own idle timeout periods.
Session idle timeout may be prevented by keep-alive strategies Session idle timeout may be prevented by keep-alive strategies
Section 4.8. Section 4.10.
The Alt-Svc "session-idle-timeout" parameter is mandatory. Session The Alt-Svc "session-idle-timeout" parameter is optional. Session
advertisments MUST contain at least one instance. If the parameter advertisements MAY contain zero or more instances of this parameter.
is repeated the first occurrence MUST be used and subsequent If it is repeated, the first occurrence MUST be used and subsequent
occurrences MUST be ignored. occurrences MUST be ignored. Session advertisements that omit the
"session-idle-timeout" parameter, or set it to zero never time out.
Receiving participants SHOULD leave multicast QUIC sessions when the Receiving participants SHOULD leave multicast QUIC sessions when the
session idle timeout period has elapsed (Section 4.7). Leaving session idle timeout period has elapsed (Section 4.7). Leaving
participants MUST use the silent close method, in which no QUIC participants MUST use the silent close method, in which no QUIC
"CONNECTION_CLOSE" frame is sent. "CONNECTION_CLOSE" frame is sent.
3.5. Session Peak Flow Rate 3.5. Session Peak Flow Rate
[QUIC-TRANSPORT] specifies a credit-based stream- and connection- [QUIC-TRANSPORT] specifies a credit-based stream- and connection-
level flow control scheme which prevents a fast sender from level flow control scheme which prevents a fast sender from
overwhelming a slow receiver. Window size connection parameters are overwhelming a slow receiver at the stream level, as well as an
exchanged on connection establishment using the required QUIC aggregate level of all streams. Window size connection parameters
TransportParameters "initial_max_data" and "initial_max_stream_data". are exchanged on connection establishment using the required QUIC
In a unidirectional multicast environment, such a scheme is TransportParameters "initial_max_data",
infeasible. This document defines a "peak flow rate" session "initial_max_stream_data_bidi_local",
parameter, expressed in units of bits per second, which is advertised "initial_max_stream_data_bidi_remote" and
as the Alt-Svc parameter "peak-flow-rate" (Section 10.2.8). This "initial_max_stream_data_uni". In a unidirectional multicast
replaces "initial_max_data" and "initial_max_stream_data" completely, environment, such a scheme is infeasible.
instead indicating the maximum bit rate of QUIC "STREAM" frame
payloads transmitted on all multicast groups comprising the session. This document defines a "peak flow rate" session parameter, expressed
in units of bits per second, which is advertised as the Alt-Svc
parameter "peak-flow-rate" (Section 10.2.8). This completely
replaces the transport parameters listed above, instead indicating
the maximum bit rate of QUIC "STREAM" frame payloads transmitted on
all multicast groups comprising the session. It applies at the
aggregate level, and is not specific to any single stream.
The Alt-Svc "peak-flow-rate" parameter is OPTIONAL. If the parameter The Alt-Svc "peak-flow-rate" parameter is OPTIONAL. If the parameter
is repeated the first occurrence MUST be used and subsequent is repeated the first occurrence MUST be used and subsequent
occurrences MUST be ignored. Session advertisements that omit the occurrences MUST be ignored. Session advertisements that omit the
parameter imply that the flow rate is unlimited. parameter imply that the flow rate is unlimited.
A multicast sender SHOULD NOT cause the advertised peak flow rate of A multicast sender SHOULD NOT cause the advertised peak flow rate of
a session to be exceeded. A receiver MAY leave any session where the a session to be exceeded. A receiver MAY leave any session where the
advertised peak flow rate is exceeded. advertised peak flow rate is exceeded.
3.6. Resource Concurrency 3.6. Resource Concurrency
[QUIC-TRANSPORT] considers concurrency in terms of the number of [QUIC-TRANSPORT] considers concurrency in terms of the number of
active incoming streams, which is varied by the receiving endpoint active incoming streams, which is varied by the receiving endpoint
adjusting the maximum Stream ID. The initial value of maximum Stream adjusting the maximum Stream ID. The initial value of maximum Stream
ID is controlled by the relevant required QUIC TransportParameters ID is controlled by the relevant required QUIC TransportParameters
"initial_max_stream_id_bidi" and "initial_max_stream_id_uni". They "initial_max_streams_bidi" and "initial_max_streams_uni". They are
are increased during the lifetime of a QUIC connection by the QUIC increased during the lifetime of a QUIC connection by the QUIC
"MAX_STREAM_ID" frame. In a unidirectional multicast environment, "MAX_STREAMS" frame. In a unidirectional multicast environment,
there is no way for a receiver to specify an initial limit nor there is no way for a receiver to specify an initial limit nor to
increase it. Therefore in multicast QUIC, the maximum Stream ID increase it. Therefore in multicast QUIC, the maximum Stream ID
(initial and always) is 2^62. This mechanism is not used to manage (initial and always) is 2^62. This mechanism is not used to manage
concurrency in multicast QUIC. concurrency in multicast QUIC.
Due to the profiling of maximum Stream ID, there is no role for the Due to the profiling of maximum Stream ID, there is no role for the
QUIC "STREAM_ID_BLOCKED" frame and it is prohibited. Participants QUIC "STREAMS_BLOCKED" frame and it is prohibited. Participants MUST
MUST NOT send this frame type. Reception of this frame type MUST be NOT send this frame type. Reception of this frame type MUST be
handled as described in Section 4.10. handled as described in Section 4.12.
This document specifies a "maximum concurrent resources" session This document specifies a "maximum concurrent resources" session
parameter, which is advertised as the Alt-Svc parameter "max- parameter, which is advertised as the Alt-Svc parameter "max-
concurrent-resources" (Section 10.2.7). This parameter replaces concurrent-resources" (Section 10.2.7). This parameter replaces
"initial_max_stream_id_bidi" and "initial_max_stream_id_uni". It "initial_max_stream_id_bidi" and "initial_max_stream_id_uni". It
advertises the maximum number of concurrent active resources advertises the maximum number of concurrent active resources
generated by a sender in a given multicast QUIC session. generated by a sender in a given multicast QUIC session.
The Alt-Svc "max-concurrent-resources" parameter is OPTIONAL. If the The Alt-Svc "max-concurrent-resources" parameter is OPTIONAL. If the
parameter is repeated the first occurrence MUST be used and parameter is repeated the first occurrence MUST be used and
skipping to change at page 17, line 38 skipping to change at page 18, line 32
The profile of [QUIC-TRANSPORT] is presented in this section. In The profile of [QUIC-TRANSPORT] is presented in this section. In
order to preserve compatibility with conventional QUIC, the order to preserve compatibility with conventional QUIC, the
specification works with a limited scope of change. However, the specification works with a limited scope of change. However, the
nature of unidirectional multicast communications means that some nature of unidirectional multicast communications means that some
protocol procedures or behaviours need to be modified. protocol procedures or behaviours need to be modified.
4.1. Packet Size 4.1. Packet Size
The means for determining an appropriate size for QUIC packets are The means for determining an appropriate size for QUIC packets are
described in Section 9 of [QUIC-TRANSPORT]. Implementations of this described in Section 14 of [QUIC-TRANSPORT]. Implementations of this
specification SHOULD bear in mind that the Path Maximum Transmission specification SHOULD bear in mind that the Path Maximum Transmission
Unit (PTMU) may be affected by multicast IP technologies such as Unit (PTMU) may be affected by multicast IP technologies such as
Automatic Multicast Tunneling (AMT) [RFC7450]. Additionally, Automatic Multicast Tunneling (AMT) [RFC7450]. Additionally,
consideration should be given toward the applicability of maximum consideration should be given toward the applicability of maximum
transmission unit discovery methods (such as PLPMTUD [RFC4821] and transmission unit discovery methods (such as PLPMTUD [RFC4821] and
PMTUD [RFC1191]) to multicast IP. PMTUD [RFC1191]) to multicast IP.
4.2. Packet Format 4.2. Packet Format
Endpoints implementing this specification MUST only send QUIC packets Endpoints implementing this specification MUST only send QUIC packets
with the short header form. This header form omits the Version with the short header form. As short header packets do not include a
field. length, senders MUST NOT attempt to coalesce any QUIC packets in the
same UDP datagram. Therefore, all UDP datagrams sent by senders
conforming to this profile contain exactly one QUIC packet.
*Authors' Note:* The authors welcome suggestions for conveying the 4.2.1. Packet Numbers
QUIC version in every multicast QUIC packet.
All packets for this profile SHALL be numbered in the application
data packet number space. The initial and handshake packet number
spaces are not used by this profile, as the handshake is replaced by
an out-of-band mechanism (see Section 2.4).
Because a recevier may join a session after the sender has already
sent several packets, it MUST NOT assume that the first packet number
will be 0.
4.2.2. Spin Bit
[QUIC-TRANSPORT] reserves a bit in the short packet header for the
latency spin bit [QUIC-SPIN] that may be used to measure network
round trip latency between a client and a server. This mechanism is
not usable in a unidirectional multicast packet flow. Senders SHALL
set the spin bit to zero in all packets. Receivers SHOULD ignore the
spin bit.
*Authors' Note:* The authors welcome suggestions for the use of
the spin bit in a multicast context.
4.3. Connection Identifier 4.3. Connection Identifier
The Connection ID field MUST be present in every QUIC packet, and the The Destination Connection ID field MUST be present in every QUIC
corresponding flag in the packet header MUST be set to indicate that packet if the session was advertised with a "session-id" session
the Connection ID field is present. parameter (Section 10.2.5). If there is no Session ID session
parameter, then the Destination Connection ID MUST NOT be present in
any QUIC packet for that session. In the case where multiple
sessions are multiplexed on the same 5-tuple network association, the
Destination Connection ID field MUST be present in every QUIC packet
and must be distinct for each session.
4.4. Stream Identifier 4.4. Stream Identifier
The maximum Stream ID of a multicast QUIC session is 2^62, as The maximum Stream ID of a multicast QUIC session is 2^62, as
explained in Section 3.6. explained in Section 3.6. With the exception of the first client-
initiated request Stream ID, which is reserved as described in
Senders MUST NOT send any QUIC frames on QUIC stream 0. Receivers Section 5.2, all Stream ID values SHALL be of the server-initiated
MUST ignore QUIC frames received on stream 0. unidirectional stream type.
4.5. Flow Control 4.5. Flow Control
Conventional QUIC provides stream- and connection-level flow control, Conventional QUIC provides stream- and connection-level flow control,
and endpoints manage this by sending QUIC "MAX_DATA" or and endpoints manage this by sending QUIC "MAX_DATA" or
"MAX_STREAM_DATA" frames as required. When a sender is blocked from "MAX_STREAM_DATA" frames as required. When a sender is blocked from
sending flow-controlled frames, it sends an informational QUIC sending flow-controlled frames, it sends an informational QUIC
"BLOCKED" or "STREAM_BLOCKED" frame. "BLOCKED" or "STREAM_BLOCKED" frame.
In a unidirectional environment, the sender never has a receive In a unidirectional environment, the sender never has a receive
window and the receiver cannot send in-band updates. Therefore, the window and the receiver cannot send in-band updates. Therefore, the
management of flow-control windows and transmission of blockage management of flow-control windows and transmission of blockage
information is not supported by this profile. The QUIC "MAX_DATA", information is not supported by this profile. The QUIC "MAX_DATA",
"MAX_STREAM_DATA", "BLOCKED" and "STREAM_BLOCKED" frames are "MAX_STREAM_DATA", "BLOCKED" and "STREAM_BLOCKED" frames are
prohibited by this profile. Participants MUST NOT send these frame prohibited by this profile. Participants MUST NOT send these frame
types. Reception of these frame types MUST be handled as described types. Reception of these frame types MUST be handled as described
in Section 4.10. in Section 4.12.
4.6. Stream Termination 4.6. Stream Termination
A sender MAY prematurely terminate the transmission on any unreserved A sender MAY prematurely terminate the transmission on any unreserved
QUIC Stream ID by setting the "FIN" bit of a QUIC "STREAM" frame, or QUIC Stream ID by setting the "FIN" bit of a QUIC "STREAM" frame, or
by sending a QUIC "RST_STREAM" frame (as specified in by sending a QUIC "RESET_STREAM" frame (as specified in
[QUIC-TRANSPORT] and [QUIC-HTTP]). [QUIC-TRANSPORT] and [QUIC-HTTP]).
Receiving participants MUST NOT make any attempt to send QUIC Receiving participants MUST NOT make any attempt to send QUIC
"RST_STREAM" frames to the multicast group. "RESET_STREAM" frames to the multicast group.
4.7. Session Shutdown 4.7. Session Shutdown
Explicit shutdown of a multicast QUIC session using QUIC methods is Explicit shutdown of a multicast QUIC session using QUIC methods is
not supported by this profile. not supported by this profile.
The QUIC "APPLICATION_CLOSE" and "CONNECTION_CLOSE" frames, and the The QUIC "APPLICATION_CLOSE" and "CONNECTION_CLOSE" frames, and the
Public Reset packet are prohibited. Participants MUST NOT send these Stateless Reset packet are prohibited. Participants MUST NOT send
and reception MUST be handled as described in Section 4.10. these and reception MUST be handled as described in Section 4.12.
The HTTP/QUIC "GOAWAY" frame is prohibited. Participants MUST NOT The HTTP/3 "GOAWAY" frame is prohibited. Participants MUST NOT send
send this and reception MUST be handled as described in Section 5.7. this and reception MUST be handled as described in Section 5.7.
*Author's Note*: Richard: Should the above be moved to the HTTP/3
profile section? (REMOVE BEFORE PUBLISHING)
Explicit session tear-down using HTTP semantics is allowed, as Explicit session tear-down using HTTP semantics is allowed, as
described in Section 5.5. described in Section 5.5.
Implicit shutdown by means of silent close is also supported, as Implicit shutdown by means of silent close is also supported, as
described in Section 3.4. described in Section 3.4.
4.8. Session Keep-alive 4.8. Connection Migration
[QUIC-TRANSPORT] has a connection migration feature that allows a
connection to survive changes to endpoint addresses. This profile
does not currently support connection migration, and as such the
"NEW_CONNECTION_ID" and "RETIRE_CONNECTION_ID" frames are prohibited.
Similarly, the "PATH_CHALLENGE" and "PATH_RESPONSE" frames are also
prohibited, but additionally because they require bidirectional
capability that this profile does not provide.
4.9. Explicit Congestion Notification
[QUIC-TRANSPORT] specifies that clients may use Explicit Congestion
Notification (ECN) [RFC3168]. ECN allows receivers to inform senders
of impending congestion before packets are dropped, and the sender
may then reduce its transmission rate. As ECN requires bidirectional
communication for the receiver to inform the sender of the
congestion, the use of ECN for this profile is prohibited.
*Author's Note*: It is the responsibility of a receiver to
determine whether network conditions permit the uncongested
reception of a given session based on the advertised "peak-flow-
rate" parameter.
4.10. Session Keep-alive
The flow of traffic in a multicast QUIC session is driven by a The flow of traffic in a multicast QUIC session is driven by a
sender. There may be periods where the sender has no application sender. There may be periods where the sender has no application
data to send for a period longer than the session idle timeout. This data to send for a period longer than the session idle timeout. This
profile repurposes the QUIC "PING" frame to act as a unidirectional profile repurposes the QUIC "PING" frame to act as a unidirectional
keep-alive message that may be sent in order to inform receivers that keep-alive message that may be sent in order to inform receivers that
the session should remain in the Fully-established state. the session should remain in the Fully-established state.
[QUIC-TRANSPORT] contains guidance on the sending frequency of QUIC [QUIC-TRANSPORT] contains guidance on the sending frequency of QUIC
"PING" frames. "PING" frames.
Senders MAY send a QUIC "PING" frame with an empty Data field at any Senders MAY send a QUIC "PING" frame at any time in order to inform
time in order to inform receivers that the session traffic flow has receivers that the session traffic flow has not fallen idle. This
not fallen idle. This frame MUST NOT be acknowledged. Indeed, QUIC frame MUST NOT be acknowledged. Indeed, QUIC "ACK" frames are
"ACK" frames are prohibited by this profile (Section 4.9). prohibited by this profile (Section 4.11).
Senders MUST NOT send a QUIC "PING" frame with a populated Data
field. This effectively means that QUIC "PONG" frames are also
prohibited by this profile.
Receiving participants MUST NOT make any attempt to send QUIC "PING" Receiving participants MUST NOT make any attempt to send QUIC "PING"
frames. frames.
4.9. Loss Detection and Recovery 4.11. Loss Detection and Recovery
Receivers implementing this profile MUST NOT make any attempt to Receivers implementing this profile MUST NOT make any attempt to
acknowledge the reception of QUIC packets. The QUIC "ACK" frame is acknowledge the reception of QUIC packets. The QUIC "ACK" frame is
prohibited for both senders and receivers. Reception of this frame prohibited for both senders and receivers. Reception of this frame
MUST be handled as described in Section 4.10. MUST be handled as described in Section 4.12.
Section 7 specifies alternative strategies for loss recovery. Section 7 specifies alternative strategies for loss recovery.
4.10. Prohibited QUIC Frames and Packets 4.12. Prohibited QUIC Frames and Packets
The following QUIC packets MUST NOT be transmitted by participants: The following QUIC packets MUST NOT be transmitted by participants:
0-RTT Protected, 1-RTT Protected (key phase 0), 1-RTT Protected (key Any packets with a long header (Initial, 0-RTT Protected, Handshake,
phase 1), Client Cleartext, Client Initial, Public Reset, Server Retry), Version Negotiation, Stateless Reset.
Cleartext, Server Initial, Version Negotiation.
The following QUIC frames MUST NOT be transmitted by participants: The following QUIC frames MUST NOT be transmitted by participants:
"ACK", "APPLICATION_CLOSE", "BLOCKED", "CONNECTION_CLOSE", "ACK", "CONNECTION_CLOSE", "CRYPTO", "DATA_BLOCKED", "MAX_DATA",
"MAX_DATA", "MAX_STREAM_ID", "MAX_STREAM_DATA", "PING" (with Data), "MAX_STREAM_DATA", "MAX_STREAMS", "NEW_CONNECTION_ID", "NEW_TOKEN",
"PONG", "STREAM_BLOCKED", "STREAM_ID_BLOCKED". "PATH_CHALLENGE", "PATH_RESPONSE", "RETIRE_CONNECTION_ID",
"STOP_SENDING", "STREAM_DATA_BLOCKED", "STREAMS_BLOCKED".
The following QUIC frames MUST NOT be transmitted by receivers: The following QUIC frames MUST NOT be transmitted by receivers:
"RST_STREAM". "PING", "RESET_STREAM".
Reception of a prohibited QUIC frame or packet is a protocol error. Reception of a prohibited QUIC frame or packet is a protocol error.
Receivers MUST ignore all prohibited QUIC frames and packets. Receivers MUST ignore all prohibited QUIC frames and packets.
5. HTTP/QUIC Profile 5. HTTP/3 Profile
*Authors' Note:* The HTTP/QUIC mapping document is subject to *Authors' Note:* The HTTP/3 mapping document is subject to change.
change. This section is based on our best understanding of draft- This section is based on our best understanding of draft-ietf-
ietf-quic-http-08. The authors will track developments and will quic-http-17. The authors will track developments and will update
update this section accordingly. this section accordingly.
HTTP over multicast QUIC depends on HTTP server push, as described in HTTP over multicast QUIC depends on HTTP server push, as described in
Section 4.4 of [QUIC-HTTP]. Section 5.2 below applies an additional Section 4.4 of [QUIC-HTTP]. Section 5.2 below applies an additional
constraint on the use of server push. A multicast sender constraint on the use of server push. A multicast sender
participating in a session pushes resources as a series of QUIC participating in a session pushes resources as a series of QUIC
"STREAM" frames carrying HTTP/QUIC "PUSH_PROMISE", "HEADERS" and "STREAM" frames carrying HTTP/3 "PUSH_PROMISE", "HEADERS" and "DATA"
"DATA" frames. Examples of this are provided in Appendix B.2. frames. Examples of this are provided in Appendix B.2. Senders MUST
Senders MUST comply with the requirements of the session parameters, comply with the requirements of the session parameters, as described
as described earlier in Section 3. earlier in Section 3.
The profile of HTTP/QUIC specified in this section places additional The profile of HTTP/3 specified in this section places additional
constrains on the use of metadata compression (Section 5.3) and constrains on the use of metadata compression (Section 5.3) and
prioritisation (Section 5.4). prioritisation (Section 5.4).
5.1. HTTP Connection Settings 5.1. HTTP Connection Settings
The HTTP/QUIC "SETTINGS" frame is prohibited by this profile. The HTTP/3 "SETTINGS" frame is prohibited by this profile.
Participants MUST NOT make any attempt to send this frame type. Participants MUST NOT make any attempt to send this frame type.
Reception of this frame MUST be handled as described in Section 5.7. Reception of this frame MUST be handled as described in Section 5.7.
5.2. Server Push 5.2. Server Push
Server push is, by default, disabled for HTTP/QUIC connections. A Server push is, by default, disabled for HTTP/3 connections. A
conventional HTTP/QUIC client enables and manages server push by conventional HTTP/3 client enables and manages server push by
controlling the maximum Push ID ([QUIC-HTTP], Section 5.2.6), controlling the maximum Push ID ([QUIC-HTTP], Section 5.2.6),
achieved by sending the HTTP/QUIC "MAX_PUSH_ID" frame. achieved by sending the HTTP/3 "MAX_PUSH_ID" frame.
This profile mandates the use of server push, and specifies no means This profile mandates the use of server push, and specifies no means
to disable it. The maximum Push ID for multicast QUIC sessions to disable it. The maximum Push ID for multicast QUIC sessions
(initial and always) is 2^62. (initial and always) is 2^62. Values of Push ID SHALL be allocated
in accordance with [QUIC-HTTP].
Server push concurrency in multicast QUIC is described in Server push concurrency in multicast QUIC is described in
Section 3.6. There is no role for the HTTP/QUIC "MAX_PUSH_ID" frame Section 3.6. There is no role for the HTTP/3 "MAX_PUSH_ID" frame and
and it is prohibited. Participants MUST NOT send this frame type. it is prohibited. Participants MUST NOT send this frame type.
Reception of this frame type MUST be handled as described in Reception of this frame type MUST be handled as described in
Section 5.7. Section 5.7.
The HTTP/QUIC "CANCEL_PUSH" frame MAY be used by sending participants When opening a stream for a new server-pushed resource, the first
to abort sending a response for the identified server push. Usage of byte on the stream is the Stream Type. For this profile, the Stream
this frame should follow the guidance for servers in [QUIC-HTTP]. Type for any new server-initiated unidirectional stream MUST be
Server Push ("P", "0x50").
Receiving participants MUST NOT make any attempt to send QUIC The HTTP/3 "CANCEL_PUSH" frame MAY be used by sending participants to
abort sending a response for the identified server push. Usage of
this frame SHALL follow the guidance for servers in [QUIC-HTTP].
Receiving participants MUST NOT make any attempt to send HTTP/3
"CANCEL_PUSH" frames to the multicast group. "CANCEL_PUSH" frames to the multicast group.
Conventionally, pushed responses are associated with an explicit Conventionally, pushed responses are associated with an explicit
request from a client. This is not possible when using a request from a client. This is not possible when using a
unidirectional transport such as multicast IP. This profile reserves unidirectional transport such as multicast IP. This profile reserves
the first client-initiated, bidirectional QUIC stream. HTTP/QUIC the first client-initiated, bidirectional QUIC stream. HTTP/3
"PUSH_PROMISE" frames MUST be sent on this reserved Stream ID. "PUSH_PROMISE" frames MUST be sent on this reserved Stream ID.
*Authors' Note:* The exact value of this Stream ID is currently in *Authors' Note:* The exact value of this Stream ID is currently in
flux. This section will track developments and will be updated flux. This section will track developments and will be updated
accordingly. The possibility of sending HTTP/QUIC "PUSH_PROMISE" accordingly. It is currently expected to be Stream ID 0.
frames on a control stream is discussed on
https://github.com/quicwg/base-drafts/issues/947.
5.3. Metadata Compression 5.3. Metadata Compression
The compression of HTTP header fields is considered in HPACK The compression of HTTP header fields is considered in QPACK
[RFC7541], which describes two methods for the compression of HTTP [QUIC-QPACK], which describes two methods for the compression of HTTP
header fields: indexing (via static or dynamic tables) and Huffman header fields: indexing (via static or dynamic tables) and Huffman
encoding. encoding.
A multicast QUIC session, as described in the present document, does A multicast QUIC session, as described in the present document, does
not provide the assurances (receiver participation, transport not provide the assurances (receiver participation, transport
reliability) required to sufficiently maintain the dynamic decoding reliability) required to sufficiently maintain the dynamic decoding
context. Therefore, this document requires that endpoints SHALL NOT context. Therefore, this document requires that endpoints SHALL NOT
use dynamic indexing. It is RECOMMENDED that endpoints use static use dynamic indexing. It is RECOMMENDED that endpoints use static
indexing and/or Huffman encoding in order to benefit from the indexing and/or Huffman encoding in order to benefit from the
remaining compression methods available. remaining compression methods available.
*Authors' Note:* In the context of QUIC, changes to HPACK may
allow for better leverage of the transport. QPACK
([I-D.bishop-quic-http-and-qpack]), QCRAM
([I-D.krasic-quic-qcram]) and QMIN ([I-D.tikhonov-quic-qmin]) are
active proposals in this space. This section will track
developments and will be updated accordingly.
5.4. Prioritisation 5.4. Prioritisation
The HTTP/QUIC "PRIORITY" frame is prohibited by this profile. The HTTP/3 "PRIORITY" frame is prohibited by this profile.
Participants MUST NOT make any attempt to send this frame type. Participants MUST NOT make any attempt to send this frame type.
Reception of this frame MUST be handled as described in Section 5.7. Reception of this frame MUST be handled as described in Section 5.7.
5.5. Session Tear-down 5.5. Session Tear-down
A multicast QUIC session MAY be explicitly torn down by means of the A multicast QUIC session MAY be explicitly torn down by means of the
"Connection: close" HTTP header described in section 6.6 of "Connection: close" HTTP header described in section 6.6 of
[RFC7230]. A sender intending to leave the session SHOULD include [RFC7230]. A sender intending to leave the session SHOULD include
the "Connection: close" header in its response metadata. A sender the "Connection: close" header in its response metadata. A sender
SHOULD transmit all outstanding frames related to remaining request/ SHOULD transmit all outstanding frames related to remaining request/
response exchanges before ending transmission to the multicast group. response exchanges before ending transmission to the multicast group.
A receiver SHOULD continue to receive and process frames until all A receiver SHOULD continue to receive and process frames until all
outstanding request/response exchanges are complete. outstanding request/response exchanges are complete.
5.6. HTTP/QUIC Extension frames 5.6. HTTP/3 Extension frames
HTTP/QUIC extension frames (e.g. "ALTSVC") are prohibited by this HTTP/3 extension frames (e.g. "ALTSVC") are prohibited by this
profile. Participants MUST NOT make any attempt to send extension profile. Participants MUST NOT make any attempt to send extension
frame types. Reception of these MUST be handled as described in frame types. Reception of these MUST be handled as described in
Section 5.7. Section 5.7.
5.7. Prohibited HTTP/QUIC Frames 5.7. Prohibited HTTP/3 Frames
The following HTTP/QUIC frames MUST NOT be transmitted by The following HTTP/3 frames MUST NOT be transmitted by participants:
participants: "GOAWAY", "MAX_PUSH_ID", "PRIORITY", "SETTINGS". "DUPLICATE_PUSH", "GOAWAY", "MAX_PUSH_ID", "PRIORITY", "SETTINGS".
In addition, all HTTP/QUIC extension frame types MUST NOT be In addition, all HTTP/3 extension frame types MUST NOT be transmitted
transmitted by participants. by participants.
The following HTTP/QUIC frames MUST NOT be transmitted by receivers: The following HTTP/3 frames MUST NOT be transmitted by receivers:
"CANCEL_PUSH". "CANCEL_PUSH".
Reception of a prohibited HTTP/QUIC frame is a protocol error. Reception of a prohibited HTTP/3 frame is a protocol error.
Receivers MUST ignore prohibited HTTP/QUIC frames. Receivers MUST ignore prohibited HTTP/3 frames.
6. Application-Layer Security 6. Application-Layer Security
As already described in Section 3.2, the implicit cipher suite used As already described in Section 3.2, the implicit cipher suite used
by a multicast QUIC session makes very limited provision for security by a multicast QUIC session makes very limited provision for security
in the transport and session layers. This section profiles the use in the transport and session layers. This section profiles the use
of some additional features to provide equivalent functionality at of some additional features to provide equivalent functionality at
the application-layer. the application-layer.
6.1. Content Integrity 6.1. Content Integrity
skipping to change at page 23, line 27 skipping to change at page 25, line 19
transmission loss or random bit errors) before passing the received transmission loss or random bit errors) before passing the received
object on to the receiving application. A mechanism is therefore object on to the receiving application. A mechanism is therefore
specified here to provide end-to-end content integrity protection for specified here to provide end-to-end content integrity protection for
HTTP representations in transit. The use of this content integrity HTTP representations in transit. The use of this content integrity
mechanism is RECOMMENDED. mechanism is RECOMMENDED.
*Authors' Note:* We invite review comments on mandating the use of *Authors' Note:* We invite review comments on mandating the use of
this content integrity mechanism. this content integrity mechanism.
[RFC3230] specifies an instance digest HTTP header called "Digest". [RFC3230] specifies an instance digest HTTP header called "Digest".
A sender MAY include this header in the HTTP/QUIC "HEADERS" frame of A sender MAY include this header in the HTTP/3 "HEADERS" frame of any
any representation it transmits and a receiver MAY use this header to representation it transmits and a receiver MAY use this header to
validate the integrity of the received representation once it has validate the integrity of the received representation once it has
been reassembled. Where this validation fails, the receiver SHOULD been reassembled. Where this validation fails, the receiver SHOULD
discard the representation without processing it further. discard the representation without processing it further.
Note that the digest value protects a whole HTTP instance (i.e. the Note that the digest value protects a whole HTTP instance (i.e. the
representation of a resource at the point of transmission as opposed representation of a resource at the point of transmission as opposed
to the body of a particular HTTP message). In cases where partial to the body of a particular HTTP message). In cases where partial
representations are fragmented over one or more HTTP response representations are fragmented over one or more HTTP response
messages, the digest value is computed over the complete messages, the digest value is computed over the complete
representation prior to fragmentation into partial responses. representation prior to fragmentation into partial responses.
skipping to change at page 24, line 23 skipping to change at page 26, line 17
signature is conveyed in the "Signature" header of the message signature is conveyed in the "Signature" header of the message
itself. The "Signature" header also conveys a list of HTTP header itself. The "Signature" header also conveys a list of HTTP header
fields over which the signature was computed. A receiver MAY verify fields over which the signature was computed. A receiver MAY verify
the "Signature" header in order to validate the authenticity of the "Signature" header in order to validate the authenticity of
received metadata. Where this validation fails, the receiver SHOULD received metadata. Where this validation fails, the receiver SHOULD
discard or ignore any related metadata and/or data without processing discard or ignore any related metadata and/or data without processing
it further. it further.
Note that the signature proves the authenticity of the metadata in a Note that the signature proves the authenticity of the metadata in a
single HTTP message. A "Signature" header MAY be included separately single HTTP message. A "Signature" header MAY be included separately
in the HTTP/QUIC "PUSH_PROMISE" frame (protecting the request in the HTTP/3 "PUSH_PROMISE" frame (protecting the request metadata)
metadata) and in the final (or only) HTTP/QUIC "HEADERS" frame and in the final (or only) HTTP/3 "HEADERS" frame relating to a
relating to a particular resource (protecting the response metadata). particular resource (protecting the response metadata). In order to
In order to provide an additional level of protection, however, it is provide an additional level of protection, however, it is RECOMMENDED
RECOMMENDED that the signature be computed over the combined request that the signature be computed over the combined request metadata
metadata (from the "PUSH_PROMISE" frame) and the corresponding (from the "PUSH_PROMISE" frame) and the corresponding response
response metadata (from the HTTP/QUIC "HEADERS" frames) of the same metadata (from the HTTP/3 "HEADERS" frames) of the same resource.
resource. This binds the request metadata and response metadata This binds the request metadata and response metadata together,
together, providing the receiver with additional reassurance of providing the receiver with additional reassurance of authenticity.
authenticity. In this latter case, the combined digital signature In this latter case, the combined digital signature SHALL be conveyed
SHALL be conveyed in the final (or only) HTTP/QUIC "HEADERS" frame. in the final (or only) HTTP/3 "HEADERS" frame.
In applications where the detection of replay attacks is a In applications where the detection of replay attacks is a
requirement, it is RECOMMENDED that the "Date" header be included in requirement, it is RECOMMENDED that the "Date" header be included in
the scope of the signature. It is RECOMMENDED that receivers use the the scope of the signature. It is RECOMMENDED that receivers use the
value of the "Date" header for replay detection using appropriate value of the "Date" header for replay detection using appropriate
strategies (e.g. checking for freshness). The definition of such strategies (e.g. checking for freshness). The definition of such
strategies is beyond the scope of this document. strategies is beyond the scope of this document.
In applications where the authenticity and integrity of the In applications where the authenticity and integrity of the
transmission are both important, it is RECOMMENDED that the "Digest" transmission are both important, it is RECOMMENDED that the "Digest"
skipping to change at page 25, line 19 skipping to change at page 27, line 11
In applications where there is a requirement for the content itself In applications where there is a requirement for the content itself
to remain confidential, appropriate steps SHOULD be taken to protect to remain confidential, appropriate steps SHOULD be taken to protect
the application payload, for example by encrypting it. This document the application payload, for example by encrypting it. This document
does not preclude the use of application-level encryption, but does does not preclude the use of application-level encryption, but does
not specify a mechanism for the distribution of content decryption not specify a mechanism for the distribution of content decryption
keys. keys.
7. Loss Recovery 7. Loss Recovery
Because the acknowledgement of received packets to multicast groups Because the acknowledgement of received packets to multicast groups
is prohibited by this specification (Section 4.9) the detection of is prohibited by this specification (Section 4.11) the detection of
discarded or corrupted packets is the sole responsibility of the discarded or corrupted packets is the sole responsibility of the
receiver, and such losses must be recovered by means other than the receiver, and such losses must be recovered by means other than the
retransmission mechanism specified in [QUIC-TRANSPORT] and retransmission mechanism specified in [QUIC-TRANSPORT] and
[QUIC-RECOVERY]. [QUIC-RECOVERY].
7.1. Forward Error Correction 7.1. Forward Error Correction
*Authors' Note:* A simple parity-based Forward Error Correction *Authors' Note:* A simple parity-based Forward Error Correction
scheme was removed from the experimental QUIC wire protocol scheme was removed from the experimental QUIC wire protocol
specification in version Q032. The IETF's QUIC Working Group is specification in version Q032. The IETF's QUIC Working Group is
skipping to change at page 25, line 48 skipping to change at page 27, line 40
7.2. Unicast Repair 7.2. Unicast Repair
In the case where a lost QUIC packet cannot be recovered using In the case where a lost QUIC packet cannot be recovered using
Forward Error Correction, either because the number of packets lost Forward Error Correction, either because the number of packets lost
exceeds the scheme's threshold for reconstruction, or because FEC is exceeds the scheme's threshold for reconstruction, or because FEC is
not in use on the multicast QUIC session, a receiver MAY instead not in use on the multicast QUIC session, a receiver MAY instead
recover the missing payload data using conventional unicast HTTP recover the missing payload data using conventional unicast HTTP
requests to an origin server. requests to an origin server.
o The total size of the resource is indicated in the "content- o The total size of the resource is indicated in the "content-
length" response header carried in the HTTP/QUIC "HEADERS" frame. length" response header carried in the HTTP/3 "HEADERS" frame.
o The location of the missing data can be determined by examining o The location of the missing data can be determined by examining
the Offset field in the QUIC "STREAM" frame headers of the Offset field in the QUIC "STREAM" frame headers of
successfully received QUIC packets. successfully received QUIC packets.
Using this information, a receiver MAY compose an efficient HTTP Using this information, a receiver MAY compose an efficient HTTP
range request [RFC7233] to the origin server indicated in the URL. range request [RFC7233] to the origin server indicated in the URL.
Several disjoint ranges MAY be combined into a single HTTP request. Several disjoint ranges MAY be combined into a single HTTP request.
A receiver MAY direct its request to an alternative server using Alt- A receiver MAY direct its request to an alternative server using Alt-
Svc information received on the multicast QUIC session, or else Svc information received on the multicast QUIC session, or else
skipping to change at page 26, line 29 skipping to change at page 28, line 19
Under certain circumstances, a sender may not be in full possession Under certain circumstances, a sender may not be in full possession
of a resource body when transmission begins, or may not be able to of a resource body when transmission begins, or may not be able to
guarantee that a transmission will complete. In such cases, the guarantee that a transmission will complete. In such cases, the
sender MAY employ the syntax of an HTTP range request [RFC7233] to sender MAY employ the syntax of an HTTP range request [RFC7233] to
indicate partial content, as specified below. All receivers SHALL indicate partial content, as specified below. All receivers SHALL
implement support for such HTTP range requests. implement support for such HTTP range requests.
If partial content is to be transmitted: If partial content is to be transmitted:
o The "range" header (Section 3.1 of [RFC7233]) SHALL be present in o The "range" header (Section 3.1 of [RFC7233]) SHALL be present in
the HTTP/QUIC "PUSH_PROMISE" frame. the HTTP/3 "PUSH_PROMISE" frame.
o The corresponding HTTP/QUIC "HEADERS" frame SHALL indicate HTTP o The corresponding HTTP/3 "HEADERS" frame SHALL indicate HTTP
status code 206. status code 206.
* The range being transmitted SHALL be indicated in a "content- * The range being transmitted SHALL be indicated in a "content-
range" header field and the size of the complete resource range" header field and the size of the complete resource
indicated in a "content-length" header field. indicated in a "content-length" header field.
9. Protocol Identifier 9. Protocol Identifier
The HTTP over multicast QUIC protocol specified in this document is The HTTP over multicast QUIC protocol specified in this document is
identified by the application-layer protocol negotiation (ALPN) identified by the application-layer protocol negotiation (ALPN)
skipping to change at page 29, line 50 skipping to change at page 31, line 45
The requirements for endpoint usage of "iv" are described in The requirements for endpoint usage of "iv" are described in
Section 3.2. Section 3.2.
10.2.5. Session Identification 10.2.5. Session Identification
This document defines the "session-id" parameter for Alt-Svc, which This document defines the "session-id" parameter for Alt-Svc, which
carries the multicast QUIC session identifier. carries the multicast QUIC session identifier.
Syntax: Syntax:
session-id = 1*16HEXDIG ; 64-bit value session-id = *HEXDIG
For example, the following specifies session 101 (0x65 hexadecimal): For example, the following specifies session 101 (0x65 hexadecimal):
session-id=65 session-id=65
The requirements for endpoint usage of "session-id" are described in The requirements for endpoint usage of "session-id" are described in
Section 2.3. Section 2.3. In the above example, the Destination Connection ID
field in every QUIC packet header would be one byte in size. For a
session-id of BADBEEF then then Destintation Connection ID field in
every QUIC packet header would be four bytes in size.
10.2.6. Session Idle Timeout Period 10.2.6. Session Idle Timeout Period
This document specifies the "session-idle-timeout" parameter for Alt- This document specifies the "session-idle-timeout" parameter for Alt-
Svc, which carries the idle timeout period of a multicast QUIC Svc, which carries the idle timeout period of a multicast QUIC
session. session.
Syntax: Syntax:
session-idle-timeout = *DIGIT ; number of seconds between 0 and 600 session-idle-timeout = *DIGIT ; number of seconds between 0 and 600
skipping to change at page 32, line 9 skipping to change at page 34, line 9
For example, the following specifies a signature algorithm of SHA- For example, the following specifies a signature algorithm of SHA-
256: 256:
signature-algorithm=rsa-sha256 signature-algorithm=rsa-sha256
The requirements for endpoint usage of "signature-algorithm" are The requirements for endpoint usage of "signature-algorithm" are
described in Section 3.9. described in Section 3.9.
11. Security and Privacy Considerations 11. Security and Privacy Considerations
This document specifies a profile of QUIC and HTTP/QUIC that changes This document specifies a profile of QUIC and HTTP/3 that changes the
the security model. In order to address this, application-level security model. In order to address this, application-level security
security methods are described in Section 6. This document does not methods are described in Section 6. This document does not preclude
preclude the use of secure multicast approaches that may provide the use of secure multicast approaches that may provide additional
additional security assurances required for certain use cases. security assurances required for certain use cases.
The use of side-channel or out-of-band technologies (potentially The use of side-channel or out-of-band technologies (potentially
bidirectional interactions) to support multicast QUIC sessions are bidirectional interactions) to support multicast QUIC sessions are
considered out of this document's scope. Services using such considered out of this document's scope. Services using such
technologies should apply their security considerations accordingly. technologies should apply their security considerations accordingly.
11.1. Pervasive Monitoring 11.1. Pervasive Monitoring
Certain multicast deployment architectures may require the use of a Certain multicast deployment architectures may require the use of a
session decryption key shared by all participants. Furthermore, the session decryption key shared by all participants. Furthermore, the
skipping to change at page 33, line 19 skipping to change at page 35, line 19
Sessions that use a symmetric key for packet protection are subject Sessions that use a symmetric key for packet protection are subject
to the possibility of a malicious actor modifying traffic at some to the possibility of a malicious actor modifying traffic at some
point in the network between a legitimate sender and one (or more) point in the network between a legitimate sender and one (or more)
receivers. Receiver-side validation, as specified in Section 6 of receivers. Receiver-side validation, as specified in Section 6 of
the present document, and also in [QUIC-TRANSPORT], allows for the the present document, and also in [QUIC-TRANSPORT], allows for the
detection of such modification. Two approaches help mitigate the detection of such modification. Two approaches help mitigate the
impact of modification; the first is application-level methods that impact of modification; the first is application-level methods that
protect data (Section 6.1) and metadata (Section 6.2); the second is protect data (Section 6.1) and metadata (Section 6.2); the second is
reduction of the QUIC packet attack surface by means of removal of reduction of the QUIC packet attack surface by means of removal of
many frame types (Section 4.10 and Section 5.7). many frame types (Section 4.12 and Section 5.7).
11.2. Protection of Discovery Mechanism 11.2. Protection of Discovery Mechanism
Multicast QUIC session advertisements SHOULD be conveyed over a Multicast QUIC session advertisements SHOULD be conveyed over a
secure transport that guarantees authenticity and integrity in order secure transport that guarantees authenticity and integrity in order
to mitigate attacks related to a malicious service advertisement, for to mitigate attacks related to a malicious service advertisement, for
example a "man in the middle" directing endpoints to a service that example a "man in the middle" directing endpoints to a service that
may lead to other attacks or exploitations. may lead to other attacks or exploitations.
*Authors' Note:* We invite review comments on mandating the use of *Authors' Note:* We invite review comments on mandating the use of
skipping to change at page 33, line 44 skipping to change at page 35, line 44
under control of, and valid for, the whole origin, as described in under control of, and valid for, the whole origin, as described in
Section 2.1 of [RFC7838]. Section 6.2 discusses measures that may be Section 2.1 of [RFC7838]. Section 6.2 discusses measures that may be
used to fulfil this requirement. used to fulfil this requirement.
11.3. Spoofing 11.3. Spoofing
11.3.1. Spoofed Ack Attacks 11.3.1. Spoofed Ack Attacks
The Spoofed "ACK" attack described in Section 13.1 of The Spoofed "ACK" attack described in Section 13.1 of
[QUIC-TRANSPORT] is out of scope because use of the QUIC "ACK" frame [QUIC-TRANSPORT] is out of scope because use of the QUIC "ACK" frame
is prohibited (Section 4.9) by the present document. is prohibited (Section 4.11) by the present document.
11.3.2. Sender Spoofing 11.3.2. Sender Spoofing
A malicious actor may be able to stage a spoof attack by sending fake A malicious actor may be able to stage a spoof attack by sending fake
QUIC packets to a multicast QUIC session. This could affect the QUIC packets to a multicast QUIC session. This could affect the
operation or behaviour of receivers. In a multicast scenario, this operation or behaviour of receivers. In a multicast scenario, this
form of attack has the potential to scale massively. form of attack has the potential to scale massively.
The feasibility of spoofing a multicast sender is governed by the The feasibility of spoofing a multicast sender is governed by the
characteristics of the multicast deployment and network characteristics of the multicast deployment and network
skipping to change at page 35, line 12 skipping to change at page 37, line 12
11.6. Denial of Service 11.6. Denial of Service
11.6.1. Unprotected Frames and Packets 11.6.1. Unprotected Frames and Packets
The handling of unprotected QUIC packets is discussed in section The handling of unprotected QUIC packets is discussed in section
9.1.4 of [QUIC-TLS]. The profile described in the present document 9.1.4 of [QUIC-TLS]. The profile described in the present document
provides the means for a multicast sender to protect QUIC packets provides the means for a multicast sender to protect QUIC packets
with a shared key, which is not a strong protection. The weak with a shared key, which is not a strong protection. The weak
protection of QUIC packets could present a denial-of-service risk. protection of QUIC packets could present a denial-of-service risk.
To mitigate the impact of handling such QUIC packets, certain frames To mitigate the impact of handling such QUIC packets, certain frames
and packets are prohibited as described in (Section 4.10 and and packets are prohibited as described in (Section 4.12 and
Section 5.7). Section 5.7).
The frame types that are allowed by this profile do not present a The frame types that are allowed by this profile do not present a
risk of denial of service. Concerns over authenticity and integrity risk of denial of service. Concerns over authenticity and integrity
are addressed by the application-layer protection mechanisms are addressed by the application-layer protection mechanisms
described in Section 6. described in Section 6.
11.6.2. Network Performance Degradation 11.6.2. Network Performance Degradation
The possibility for malfunctioning or malicious participants to The possibility for malfunctioning or malicious participants to
skipping to change at page 38, line 32 skipping to change at page 40, line 32
13. References 13. References
13.1. Normative References 13.1. Normative References
[I-D.cavage-http-signatures] [I-D.cavage-http-signatures]
Cavage, M. and M. Sporny, "Signing HTTP Messages", draft- Cavage, M. and M. Sporny, "Signing HTTP Messages", draft-
cavage-http-signatures-10 (work in progress), May 2018. cavage-http-signatures-10 (work in progress), May 2018.
[QUIC-HTTP] [QUIC-HTTP]
Bishop, M., Ed., "Hypertext Transfer Protocol (HTTP) over Bishop, M., Ed., "Hypertext Transfer Protocol Version 3
QUIC", draft-ietf-quic-http-08 (work in progress). (HTTP/3)", draft-ietf-quic-http-18 (work in progress).
[QUIC-QPACK]
Krasic, C., Ed., Bishop, M., Ed., and A. Frindell, Ed.,
"QPACK: Header Compression for HTTP over QUIC", draft-
ietf-quic-qpack-06 (work in progress).
[QUIC-TRANSPORT] [QUIC-TRANSPORT]
Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport", draft-ietf-quic- Multiplexed and Secure Transport", draft-ietf-quic-
transport-08 (work in progress). transport-18 (work in progress).
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP",
RFC 3168, DOI 10.17487/RFC3168, September 2001,
<https://www.rfc-editor.org/info/rfc3168>.
[RFC3230] Mogul, J. and A. Van Hoff, "Instance Digests in HTTP", [RFC3230] Mogul, J. and A. Van Hoff, "Instance Digests in HTTP",
RFC 3230, DOI 10.17487/RFC3230, January 2002, RFC 3230, DOI 10.17487/RFC3230, January 2002,
<https://www.rfc-editor.org/info/rfc3230>. <https://www.rfc-editor.org/info/rfc3230>.
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for
IP", RFC 4607, DOI 10.17487/RFC4607, August 2006, IP", RFC 4607, DOI 10.17487/RFC4607, August 2006,
<https://www.rfc-editor.org/info/rfc4607>. <https://www.rfc-editor.org/info/rfc4607>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, Specifications: ABNF", STD 68, RFC 5234,
skipping to change at page 39, line 44 skipping to change at page 42, line 11
[RFC7838] Nottingham, M., McManus, P., and J. Reschke, "HTTP [RFC7838] Nottingham, M., McManus, P., and J. Reschke, "HTTP
Alternative Services", RFC 7838, DOI 10.17487/RFC7838, Alternative Services", RFC 7838, DOI 10.17487/RFC7838,
April 2016, <https://www.rfc-editor.org/info/rfc7838>. April 2016, <https://www.rfc-editor.org/info/rfc7838>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
13.2. Informative References 13.2. Informative References
[I-D.bishop-quic-http-and-qpack]
Bishop, M., "Header Compression for HTTP/QUIC", draft-
bishop-quic-http-and-qpack-07 (work in progress), December
2017.
[I-D.krasic-quic-qcram]
Krasic, C., "Header Compression for HTTP over QUIC",
draft-krasic-quic-qcram-04 (work in progress), January
2018.
[I-D.tikhonov-quic-qmin]
Tikhonov, D., "QMIN: Header Compression for QUIC", draft-
tikhonov-quic-qmin-00 (work in progress), November 2017.
[QUIC-RECOVERY] [QUIC-RECOVERY]
Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection
and Congestion Control", draft-ietf-quic-recovery-08 (work and Congestion Control", draft-ietf-quic-recovery-18 (work
in progress). in progress).
[QUIC-SPIN]
Trammell, B., Ed. and M. Kuehlewind, "The QUIC Latency
Spin Bit", draft-ietf-quic-spin-exp-01 (work in progress).
[QUIC-TLS] [QUIC-TLS]
Thomson, M., Ed. and S. Turner, Ed, Ed., "Using Transport Thomson, M., Ed. and S. Turner, Ed, Ed., "Using Transport
Layer Security (TLS) to Secure QUIC", draft-ietf-quic- Layer Security (TLS) to Secure QUIC", draft-ietf-quic-
tls-08 (work in progress). tls-18 (work in progress).
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5,
RFC 1112, DOI 10.17487/RFC1112, August 1989, RFC 1112, DOI 10.17487/RFC1112, August 1989,
<https://www.rfc-editor.org/info/rfc1112>. <https://www.rfc-editor.org/info/rfc1112>.
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
DOI 10.17487/RFC1191, November 1990, DOI 10.17487/RFC1191, November 1990,
<https://www.rfc-editor.org/info/rfc1191>. <https://www.rfc-editor.org/info/rfc1191>.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
skipping to change at page 41, line 23 skipping to change at page 43, line 28
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU
Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007,
<https://www.rfc-editor.org/info/rfc4821>. <https://www.rfc-editor.org/info/rfc4821>.
[RFC5737] Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks [RFC5737] Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks
Reserved for Documentation", RFC 5737, Reserved for Documentation", RFC 5737,
DOI 10.17487/RFC5737, January 2010, DOI 10.17487/RFC5737, January 2010,
<https://www.rfc-editor.org/info/rfc5737>. <https://www.rfc-editor.org/info/rfc5737>.
[RFC5740] Adamson, B., Bormann, C., Handley, M., and J. Macker,
"NACK-Oriented Reliable Multicast (NORM) Transport
Protocol", RFC 5740, DOI 10.17487/RFC5740, November 2009,
<https://www.rfc-editor.org/info/rfc5740>.
[RFC6676] Venaas, S., Parekh, R., Van de Velde, G., Chown, T., and [RFC6676] Venaas, S., Parekh, R., Van de Velde, G., Chown, T., and
M. Eubanks, "Multicast Addresses for Documentation", M. Eubanks, "Multicast Addresses for Documentation",
RFC 6676, DOI 10.17487/RFC6676, August 2012, RFC 6676, DOI 10.17487/RFC6676, August 2012,
<https://www.rfc-editor.org/info/rfc6676>. <https://www.rfc-editor.org/info/rfc6676>.
[RFC6726] Paila, T., Walsh, R., Luby, M., Roca, V., and R. Lehtonen,
"FLUTE - File Delivery over Unidirectional Transport",
RFC 6726, DOI 10.17487/RFC6726, November 2012,
<https://www.rfc-editor.org/info/rfc6726>.
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
2014, <https://www.rfc-editor.org/info/rfc7258>. 2014, <https://www.rfc-editor.org/info/rfc7258>.
[RFC7450] Bumgardner, G., "Automatic Multicast Tunneling", RFC 7450, [RFC7450] Bumgardner, G., "Automatic Multicast Tunneling", RFC 7450,
DOI 10.17487/RFC7450, February 2015, DOI 10.17487/RFC7450, February 2015,
<https://www.rfc-editor.org/info/rfc7450>. <https://www.rfc-editor.org/info/rfc7450>.
[RFC7541] Peon, R. and H. Ruellan, "HPACK: Header Compression for
HTTP/2", RFC 7541, DOI 10.17487/RFC7541, May 2015,
<https://www.rfc-editor.org/info/rfc7541>.
[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085,
March 2017, <https://www.rfc-editor.org/info/rfc8085>. March 2017, <https://www.rfc-editor.org/info/rfc8085>.
Appendix A. Acknowledgements Appendix A. Acknowledgements
The authors would like to thank the following for their contributions The authors would like to thank the following for their contributions
to the design described in the present document: Brandon Butterworth, to the design described in the present document: Brandon Butterworth,
Sam Hurst, Chris Poole, Craig Taylor and David Waring. Chris Poole, Craig Taylor and David Waring.
We are also grateful to Thomas Swindells and Magnus Westerlund for We are also grateful to Thomas Swindells and Magnus Westerlund for
their helpful review comments. their helpful review comments.
Appendix B. Examples Appendix B. Examples
This appendix contains examples of multicast QUIC session This appendix contains examples of multicast QUIC session
advertisement and resource transfer (with and without application- advertisement and resource transfer (with and without application-
layer content security). layer content security).
skipping to change at page 43, line 33 skipping to change at page 45, line 46
session-id=10; session-idle-timeout=60; session-id=10; session-idle-timeout=60;
max-concurrent-resources=10; peak-flow-rate=10000; max-concurrent-resources=10; peak-flow-rate=10000;
cipher-suite=1301; key=4adf1eab9c2a37fd; iv=4dbe593acb4d1577ad6ba7dc3189834e cipher-suite=1301; key=4adf1eab9c2a37fd; iv=4dbe593acb4d1577ad6ba7dc3189834e
digest-algorithm=SHA-256; signature-algorithm=rsa-sha256 digest-algorithm=SHA-256; signature-algorithm=rsa-sha256
B.2. Resource Transfer B.2. Resource Transfer
This section shows several different examples of the HTTP message This section shows several different examples of the HTTP message
patterns for a single resource. patterns for a single resource.
Examples that show HTTP/QUIC "PUSH_PROMISE" or "HEADERS" frames Examples that show HTTP/3 "PUSH_PROMISE" or "HEADERS" frames describe
describe the contents of enclosed header block fragments. the contents of enclosed header block fragments.
B.2.1. Transfer without Content Integrity or Authenticity B.2.1. Transfer without Content Integrity or Authenticity
HTTP/QUIC "PUSH_PROMISE" frame: HTTP/3 "PUSH_PROMISE" frame:
:method: GET :method: GET
:scheme: https :scheme: https
:path: /files/example.txt :path: /files/example.txt
:authority: example.org :authority: example.org
HTTP/QUIC "HEADERS" frame; HTTP/3 "HEADERS" frame;
:status: 200 :status: 200
content-length: 100 content-length: 100
content-type: text/plain content-type: text/plain
date: Fri, 20 Jan 2017 10:00:00 GMT date: Fri, 20 Jan 2017 10:00:00 GMT
HTTP/QUIC "DATA" frame containing 100 bytes of response body data: HTTP/3 "DATA" frame containing 100 bytes of response body data:
... ...
B.2.2. Transfer of Partial Content without Content Integrity or B.2.2. Transfer of Partial Content without Content Integrity or
Authenticity Authenticity
In this example, partial content is transferred as described in In this example, partial content is transferred as described in
Section 8. The "Range" request header is used to indicate the Section 8. The "Range" request header is used to indicate the
sender's original intention to transfer all 100 bytes of the sender's original intention to transfer all 100 bytes of the
representation. The "Content-Range" response header indicates that representation. The "Content-Range" response header indicates that
only the first 50 bytes were actually sent. only the first 50 bytes were actually sent.
HTTP/QUIC "PUSH_PROMISE" frame: HTTP/3 "PUSH_PROMISE" frame:
:method: GET :method: GET
:scheme: https :scheme: https
:path: /files/example.txt :path: /files/example.txt
:authority: example.org :authority: example.org
range: bytes=0-* range: bytes=0-*
HTTP/QUIC "HEADERS" frame: HTTP/3 "HEADERS" frame:
:status: 206 :status: 206
content-length: 100 content-length: 100
content-range: bytes 0-49/100 content-range: bytes 0-49/100
content-type: text/plain content-type: text/plain
date: Fri, 20 Jan 2017 10:00:00 GMT date: Fri, 20 Jan 2017 10:00:00 GMT
HTTP/QUIC "DATA" frame containing 50 bytes of response body data: HTTP/3 "DATA" frame containing 50 bytes of response body data:
... ...
B.2.3. Transfer with Content Integrity and without Authenticity B.2.3. Transfer with Content Integrity and without Authenticity
In this example, content integrity is assured by the inclusion of the In this example, content integrity is assured by the inclusion of the
"Digest" response header, as described in Section 6.1. "Digest" response header, as described in Section 6.1.
HTTP/QUIC "PUSH_PROMISE" frame: HTTP/3 "PUSH_PROMISE" frame:
:method: GET :method: GET
:scheme: https :scheme: https
:path: /files/example.txt :path: /files/example.txt
:authority: example.org :authority: example.org
HTTP/QUIC "HEADERS" frame including the "Digest" header: HTTP/3 "HEADERS" frame including the "Digest" header:
:status: 200 :status: 200
content-length: 100 content-length: 100
content-type: text/plain content-type: text/plain
date: Fri, 20 Jan 2017 10:00:00 GMT date: Fri, 20 Jan 2017 10:00:00 GMT
digest: SHA-256=DieQ9zfRaDdyAilTVCvmBePuxMm+B6cNocP+QCrNSqo= digest: SHA-256=DieQ9zfRaDdyAilTVCvmBePuxMm+B6cNocP+QCrNSqo=
HTTP/QUIC "DATA" frame containing 100 bytes of response body data: HTTP/3 "DATA" frame containing 100 bytes of response body data:
... ...
B.2.4. Partial Transfer with Content Integrity and without Authenticity B.2.4. Partial Transfer with Content Integrity and without Authenticity
In this example, partial content is transferred as described in In this example, partial content is transferred as described in
Section 8. The "Range" request header is used to indicate the Section 8. The "Range" request header is used to indicate the
sender's intention to transfer all 100 bytes of the representation. sender's intention to transfer all 100 bytes of the representation.
The "Content-Range" response header indicates that only the first 50 The "Content-Range" response header indicates that only the first 50
bytes were actually sent. Content integrity is assured by the bytes were actually sent. Content integrity is assured by the
inclusion of the "Digest" response header, as described in inclusion of the "Digest" response header, as described in
Section 6.1. Section 6.1.
HTTP/QUIC "PUSH_PROMISE" frame: HTTP/3 "PUSH_PROMISE" frame:
:method: GET :method: GET
:scheme: https :scheme: https
:path: /files/example.txt :path: /files/example.txt
:authority: example.org :authority: example.org
range: bytes=0-* range: bytes=0-*
HTTP/QUIC "HEADERS" frame including the "Digest" header: HTTP/3 "HEADERS" frame including the "Digest" header:
:status: 206 :status: 206
content-length: 100 content-length: 100
content-range: bytes 0-49/100 content-range: bytes 0-49/100
content-type: text/plain content-type: text/plain
date: Fri, 20 Jan 2017 10:00:00 GMT date: Fri, 20 Jan 2017 10:00:00 GMT
digest: SHA-256=DieQ9zfRaDdyAilTVCvmBePuxMm+B6cNocP+QCrNSqo= digest: SHA-256=DieQ9zfRaDdyAilTVCvmBePuxMm+B6cNocP+QCrNSqo=
HTTP/QUIC "DATA" frame containing 50 bytes of response body data: HTTP/3 "DATA" frame containing 50 bytes of response body data:
... ...
B.2.5. Transfer with Content Integrity and Authenticity B.2.5. Transfer with Content Integrity and Authenticity
In this example, content integrity is assured by the inclusion of the In this example, content integrity is assured by the inclusion of the
"Digest" response header, as described in Section 6.1. Content "Digest" response header, as described in Section 6.1. Content
authenticity is assured separately for the request and the response authenticity is assured separately for the request and the response
messages by the "Signature" header which protects the header fields messages by the "Signature" header which protects the header fields
described in further detail below. The "Signature" header parameter described in further detail below. The "Signature" header parameter
"keyId" contains the URL of a file containing the public key related "keyId" contains the URL of a file containing the public key related
to the multicast sender's private key used to create the digital to the multicast sender's private key used to create the digital
signature. signature.
HTTP/QUIC "PUSH_PROMISE" frame including a "Signature" header HTTP/3 "PUSH_PROMISE" frame including a "Signature" header protecting
protecting the ":method" and ":path" (the request target), as well as the ":method" and ":path" (the request target), as well as the
the ":scheme" and ":authority" of the pseudo-request: ":scheme" and ":authority" of the pseudo-request:
:method: GET :method: GET
:scheme: https :scheme: https
:path: /files/example.txt :path: /files/example.txt
:authority: example.org :authority: example.org
signature: keyId="https://example.org/mcast-sender.example.org.pem", signature: keyId="https://example.org/mcast-sender.example.org.pem",
algorithm=rsa-sha256, algorithm=rsa-sha256,
headers="(request-target) :scheme :authority", headers="(request-target) :scheme :authority",
signature="MGQCMFTaFptaM2FhgzJq2i9AaChuFDHjp6GiXVtRnI8BsA" signature="MGQCMFTaFptaM2FhgzJq2i9AaChuFDHjp6GiXVtRnI8BsA"
HTTP/QUIC "HEADERS" frame including a "Signature" header protecting HTTP/3 "HEADERS" frame including a "Signature" header protecting the
the ":method", ":path", ":scheme" and ":authority" of the pseudo- ":method", ":path", ":scheme" and ":authority" of the pseudo-request
request above, plus the "Date" and "Digest" of the response: above, plus the "Date" and "Digest" of the response:
:status: 200 :status: 200
content-length: 100 content-length: 100
content-type: text/plain content-type: text/plain
date: Fri, 20 Jan 2017 10:00:00 GMT date: Fri, 20 Jan 2017 10:00:00 GMT
digest: SHA-256=DieQ9zfRaDdyAilTVCvmBePuxMm+B6cNocP+QCrNSqo= digest: SHA-256=DieQ9zfRaDdyAilTVCvmBePuxMm+B6cNocP+QCrNSqo=
signature: keyId="https://example.org/mcast-sender.example.org.pem", signature: keyId="https://example.org/mcast-sender.example.org.pem",
algorithm=rsa-sha256, algorithm=rsa-sha256,
headers="(request-target) :scheme :authority date digest", headers="(request-target) :scheme :authority date digest",
signature="MGUCMBgx6cuwTzg0W29zNUra8xfMsEcb3rFA3Y" signature="MGUCMBgx6cuwTzg0W29zNUra8xfMsEcb3rFA3Y"
HTTP/QUIC "DATA" frame containing response body data: HTTP/3 "DATA" frame containing response body data:
... ...
B.2.6. Partial Transfer with Content Integrity and Authenticity B.2.6. Partial Transfer with Content Integrity and Authenticity
In this example, partial content is transferred and the "Range" In this example, partial content is transferred and the "Range"
header (as described in Section 8) is used to indicate that 50 bytes header (as described in Section 8) is used to indicate that 50 bytes
out of 100 bytes were transferred. Content integrity is provided by out of 100 bytes were transferred. Content integrity is provided by
the inclusion of the "Digest" header, as described in Section 6.1. the inclusion of the "Digest" header, as described in Section 6.1.
Authenticity is provided by the "Signature" header which protects the Authenticity is provided by the "Signature" header which protects the
header fields described in further detail. The "Signature" header header fields described in further detail. The "Signature" header
parameter "keyId" contains the URL of a file containing the public parameter "keyId" contains the URL of a file containing the public
key related to the multicast sender's private key used to create the key related to the multicast sender's private key used to create the
digital signature. digital signature.
HTTP/QUIC "PUSH_PROMISE" frame: HTTP/3 "PUSH_PROMISE" frame:
:method: GET :method: GET
:scheme: https :scheme: https
:path: /files/example.txt :path: /files/example.txt
:authority: example.org :authority: example.org
range: bytes=0-* range: bytes=0-*
signature: keyId="https://example.org/mcast-sender.example.org.pem", signature: keyId="https://example.org/mcast-sender.example.org.pem",
algorithm=rsa-sha256, algorithm=rsa-sha256,
headers="(request-target) :scheme :authority range", headers="(request-target) :scheme :authority range",
signature="MGQCMFTaFptaM2FhgzJq2i9AaChuFDHjp6GiXVtRnI8BsA" signature="MGQCMFTaFptaM2FhgzJq2i9AaChuFDHjp6GiXVtRnI8BsA"
HTTP/QUIC "HEADERS" frame protecting the ":method", ":path", HTTP/3 "HEADERS" frame protecting the ":method", ":path", ":scheme"
":scheme" and ":authority" of the pseudo-request above, plus the and ":authority" of the pseudo-request above, plus the "Date",
"Date", "Digest" and "Content-Range" of the response: "Digest" and "Content-Range" of the response:
:status: 206 :status: 206
content-length: 100 content-length: 100
content-range: bytes 0-49/100 content-range: bytes 0-49/100
content-type: text/plain content-type: text/plain
date: Fri, 20 Jan 2017 10:00:00 GMT date: Fri, 20 Jan 2017 10:00:00 GMT
digest: SHA-256=DieQ9zfRaDdyAilTVCvmBePuxMm+B6cNocP+QCrNSqo= digest: SHA-256=DieQ9zfRaDdyAilTVCvmBePuxMm+B6cNocP+QCrNSqo=
signature: keyId="https://example.org/mcast-sender.example.org.pem", signature: keyId="https://example.org/mcast-sender.example.org.pem",
algorithm=rsa-sha256, algorithm=rsa-sha256,
headers="(request-target) :scheme :authority headers="(request-target) :scheme :authority
date digest content-range", date digest content-range",
signature="MGUCMBgx6cuwTzg0W29zNUra8xfMsEcb3rFA3Y" signature="MGUCMBgx6cuwTzg0W29zNUra8xfMsEcb3rFA3Y"
HTTP/QUIC "DATA" frame containing response body data: HTTP/3 "DATA" frame containing response body data:
... ...
Appendix C. Summary of differences from unicast QUIC and HTTP/QUIC Appendix C. Summary of differences from unicast QUIC and HTTP/3
+----------------+-------------------------+------------------------+ +----------------+-----------------------+--------------------------+
| Protocol | Unicast QUIC | Multicast HTTP/QUIC | | Protocol | Unicast QUIC | Multicast QUIC profile |
| feature | | profile | | feature | | |
+----------------+-------------------------+------------------------+ +----------------+-----------------------+--------------------------+
| Stream ID 0 | Combined cryptography | Reserved Stream ID not | | Packet number | QUIC transport | All packets are numbered |
| | and transport handshake | used. | | spaces | packets are seperated | in the application data |
| | stream conveying TLS | | | | into three distinct | packet number space. |
| | handshake messages in | | | | packet number spaces: | |
| | QUIC "STREAM" frames. | | | | initial, handshake | |
| | | | | | and application data. | |
| TLS cipher | Client's preferred | Cipher suite | | | | |
| suite | cipher suite included | optionally advertised | | Transport | Combined | Not used. |
| | in Client Hello | out of band via Alt- | | handshake | cryptographic and | |
| | message. | Svc "cipher-suite" | | | transport handshake | |
| | | parameter. Default | | | stream conveying TLS | |
| | | cipher suite is | | | handshake messages in | |
| | | "0x00,0x00 (NULL_WITH_ | | | QUIC Initial and | |
| | | NULL_NULL)". | | | Handshake packets. | |
| | | | | | | |
| TLS session | Session key included in | Session key optionally | | TLS cipher | Client's preferred | Cipher suite optionally |
| key | Server Hello message. | advertised out of band | | suite | cipher suite included | advertised out of band |
| | | via Alt-Svc "key" | | | in Client Hello | via Alt-Svc "cipher- |
| | | parameter. | | | message. | suite" parameter. |
| | | | | | | Default cipher suite is |
| TLS | Initialization vector | Initialization vector | | | | "0x00,0x00 |
| initialization | included in Server | optionally advertised | | | | (NULL_WITH_NULL_NULL)". |
| vector | Hello message. | out of band via Alt- | | | | |
| | | Svc "iv" parameter. | | TLS session | Session key included | Session key optionally |
| | | | | key | in Server Hello | advertised out of band |
| Required QUIC | "idle_timeout" | Advertised out of band | | | message. | via Alt-Svc "key" |
| TransportParam | | via Alt-Svc "session- | | | | parameter. |
| eter for idle | | idle-timeout" | | | | |
| timeout | | parameter. | | TLS | Initialization vector | Initialization vector |
| | | | | initialization | included in Server | optionally advertised |
| Required QUIC | "initial_max_data" | Not Used. Peak flow | | vector | Hello message. | out of band via Alt-Svc |
| TransportParam | | rate of a session | | | | "iv" parameter. |
| eter for | | optionally advertised | +----------------+-----------------------+--------------------------+
| connection | | out of band via Alt- |
| flow control | | Svc "peak-flow-rate" |
| | | parameter. |
| | | |
| Required QUIC | "initial_max_stream_ | Not used. Peak flow |
| TransportParam | data" | rate of a session |
| eter for | | optionally advertised |
| stream flow | | out of band via Alt- |
| control | | Svc "peak-flow-rate" |
| | | parameter. |
| | | |
| Required QUIC | "initial_max_stream_id_ | Not used. Maximum |
| TransportParam | bidi" and "initial_max_ | concurrent resources |
| eter for | stream_id_uni" | in a session |
| stream | | optionally advertised |
| concurrency | | out of band via Alt- |
| | | Svc "max-concurrent- |
| | | resources" parameter. |
+----------------+-------------------------+------------------------+
Table 1: Cryptography and Transport Parameters Table 1: Cryptography and Transport
+-------------+----------------+--------------------------------------+ +----------------------------+----------------+---------------------+
| Protocol | Unicast QUIC | Multicast HTTP/QUIC profile | | Protocol feature | Unicast QUIC | Multicast QUIC |
| feature | | | | | | profile |
+-------------+----------------+--------------------------------------+ +----------------------------+----------------+---------------------+
| Maximum | Determined by | Determined by path MTU discovery or | | "initial_max_data" | Connection- | Not used. Peak flow |
| packet size | path MTU | other heuristic. | | | level flow | rate of a session |
| | discovery or | | | | control window | optionally |
| | other | | | | size. | advertised out of |
| | heuristic. | | | | | band via Alt-Svc |
| | | | | | | "peak-flow-rate" |
| Version | Protocol | Not permitted. (No negotiation | | | | parameter. |
| negotiation | version | possible in multicast context.) | | | | |
| packet | negotiation | "VERSION" flag in QUIC packet header | | "initial_max_stream_data_b | Locally- | Not used. No |
| | between | must never be set. Protocol version | | idi_local" | initiated | bidirectional |
| | initiating | advertised out of band via Alt-Svc | | | bidirectional | streams in this |
| | client and | "quic" parameter. | | | stream flow | profile. |
| | server. | | | | control window | |
| | | | | | size. | |
| Public | Connection | Not permitted. (Potential denial-of- | | | | |
| reset | reset. | service attack vector.) | | "initial_max_stream_data_b | Remotely- | Not used. No |
| packet | | "PUBLIC_RESET" flag in QUIC packet | | idi_remote" | initiated | bidirectional |
| | | header must never be set. | | | bidirectional | streams in this |
| | | | | | stream flow | profile. |
| Regular | Used to convey | Used to convey QUIC frames (see | | | control window | |
| packet | QUIC frames | below). Only the short header form | | | size. | |
| | (see below). | is permitted. | | | | |
| | | | | "initial_max_stream_data_u | Unidirectional | Not used. Peak flow |
| Connection | Randomly | Redefined to be a multicast Session | | ni" | stream flow | rate of a session |
| ID field | assigned by | ID. Value assigned by the multicast | | | control window | optionally |
| | initiating | sender. Connection ID field is | | | size. | advertised out of |
| | client and/or | present in all multicast QUIC | | | | band via Alt-Svc |
| | server. | packets. "CONNECTION_ID" flag in | | | | "peak-flow-rate |
| | Different | QUIC packet header must always be | | | | parameter". |
| | Connection IDs | set. The same Session ID may span | | | | |
| | may not be | several multicast groups. Different | | "initial_max_streams_bidi" | Maximum stream | Not used. Maximum |
| | multiplexed on | Session IDs may be multiplexed on | | and | concurrency. | concurrent |
| | the same | the same 5-tuple source-specific | | "initial_max_streams_uni" | | resources in a |
| | 5-tuple | multicast group and port. | | | | session optionally |
| | network | | | | | advertised out of |
| | association? | | | | | band via Alt-Svc |
+-------------+----------------+--------------------------------------+ | | | "max-concurrent- |
| | | resources" |
| | | parameter. |
+----------------------------+----------------+---------------------+
Table 2: QUIC Packet Layer Table 2: Required Transport Parameters
+---------------------+-------------------------+---------------------+ +------------------------+------------------+-----------------------+
| Protocol feature | Unicast QUIC | Multicast HTTP/QUIC | | Protocol feature | Unicast QUIC | Multicast QUIC |
| | | profile | | | | profile |
+---------------------+-------------------------+---------------------+ +------------------------+------------------+-----------------------+
| "ACK" frame | Used by a receiver to | Prohibited. | | "original_connection_i | The value of the | Not used. No client |
| | acknowledge receipt of | | | d" | Destination | interaction. |
| | data from its peer. | | | | Connection ID | |
| | | | | | field from the | |
| "APPLICATION_CLOSE" | Notification (by either | Prohibited. | | | first Initial | |
| frame | endpoint) of immediate | | | | packet sent by | |
| | connection closure. | | | | the client. | |
| | | | | | | |
| "BLOCKED" frame | Notification to | Prohibited. | | "idle_timeout" | How long to keep | Not used. Advertised |
| | receiver that sender's | | | | an idle | out of band via Alt- |
| | transmission is blocked | | | | connection open | Svc "session-idle- |
| | pending an update to | | | | for before | timeout" parameter; |
| | its flow control window | | | | closing. Takes a | defaults to 0 (never |
| | by peer. | | | | default of 0 | close on idle) if not |
| | | | | | (never close on | specified. |
| "CONNECTION_CLOSE" | Notification (by either | Prohibited. Use | | | idle) if not | |
| frame | endpoint) of immediate | HTTP explicit | | | specified. | |
| | connection closure. | session tear-down | | | | |
| | | instead (see | | "stateless_reset_token | Used in | Not used. Stateless |
| | | HTTP/QUIC mapping | | " | verifying a | reset is not used by |
| | | below). | | | stateless reset. | this profile. |
| | | | | | | |
| "MAX_DATA" frame | Flow control update | Prohibited. | | "max_packet_size" | Limit of the | Not used. Maximum |
| | notification. | | | | size of packets | packet size for a |
| | | | | | that an endpoint | session optionally |
| "MAX_STREAM_DATA" | Flow control update | Prohibited. | | | is willing to | advertised out of |
| frame | notification. | | | | receive. | band via Alt-Svc |
| | | | | | | "max-packet-size" |
| "MAX_STREAM_ID" | Used by an endpoint to | Prohibited. | | | | parameter. |
| frame | inform a peer of the | | | | | |
| | maximum stream ID that | | | "ack_delay_exponent" | The exponent | Not used. "ACK" |
| | it is permitted to | | | | used to decode | frames are prohibited |
| | open. | | | | the ACK Delay | by this profile. |
| | | | | | field in the | |
| "PADDING" frame | Used to pad out a QUIC | Permitted, but | | | "ACK" frame. | |
| | packet with zero bytes. | wasteful of network | | | | |
| | (The first packet sent | capacity. | | "max_ack_delay" | Maximum time in | Not used. "ACK" |
| | on a connection must be | | | | milliseconds by | frames are prohibited |
| | at least 1200 bytes | | | | which an | by this profile. |
| | long to prove that the | | | | endpoint will | |
| | network can transmit | | | | delay sending ac | |
| | packets of at least | | | | knowledgements. | |
| | this size.) | | | | | |
| | | | | "disable_migration" | Signals if an | Not used. Session |
| "PING" frame | Used by an endpoint to | Used by the | | | endpoint does | migration not |
| | verify that its peer is | multicast sender as | | | not support | currently supported |
| | still alive. | a session keep- | | | connection | by this profile. |
| | Acknowledged using | alive notification. | | | migration. | |
| | "PING" or "PONG" | "PING" with data is | | | | |
| | | prohibited. Never | | "preferred_address" | Used to effect a | Not used. No |
| | | acknowledged. | | | change in server | handshake in this |
| | | | | | address at the | profile. |
| "PONG" frame | Sent in response to a | Prohibited. | | | end of the | |
| | PING frame that | | | | handshake. | |
| | contains data. | | +------------------------+------------------+-----------------------+
| | | |
| "RST_STREAM" frame | Request by receiver for | Indication to |
| | sender to terminate a | receivers that the |
| | stream transmission | multicast sender |
| | prematurely. | has prematurely |
| | | terminated a stream |
| | | transmission. It is |
| | | prohibited for |
| | | receivers to send. |
| | | |
| "STREAM" frame | Conveys application- | Conveys |
| | layer payloads (see | application-layer |
| | HTTP/QUIC mapping | payloads (see |
| | below). | HTTP/QUIC mapping |
| | | below). |
| | | |
| "FIN" bit on | Indication by sender to | Indication by the |
| "STREAM" frame | its peer that a stream | multicast sender |
| | transmission has | that a stream |
| | finished. | transmission has |
| | | finished. |
| | | |
| "STREAM_BLOCKED" | Notification to | Prohibited. |
| frame | receiver that sender's | |
| | transmission is blocked | |
| | pending an update to | |
| | its flow control window | |
| | by peer. | |
| | | |
| "STREAM_ID_BLOCKED" | Used when a sender | Prohibited. |
| frame | wishes to open a stream | |
| | but is unable to do so | |
| | because of the maximum | |
| | stream ID. | |
+---------------------+-------------------------+---------------------+
Table 3: QUIC Framing Layer Table 3: Optional Transport Parameters
+----------------+------------------+-------------------------------+ +-------------+---------------------+-------------------------------+
| Protocol | Unicast | Multicast HTTP/QUIC profile | | Protocol | Unicast QUIC | Multicast QUIC profile |
| feature | HTTP/QUIC | | | feature | | |
+----------------+------------------+-------------------------------+ +-------------+---------------------+-------------------------------+
| "ALTSVC" frame | Signalling | Prohibited. | | Maximum | Determined by path | Determined by path MTU |
| | alternative | | | packet size | MTU discovery or | discovery or other heuristic. |
| | service for | | | | other heuristic. | |
| | HTTP/QUIC | | | | | |
| | session. | | | Long header | Used for packets | Prohibited. |
| | | | | packet | that are sent prior | |
| "CANCEL_PUSH" | Used to request | Permitted only for senders. | | | to the completion | |
| frame | cancellation of | | | | of version | |
| | server push | | | | negotiation and | |
| | prior to the | | | | before packet | |
| | push stream | | | | protection keys are | |
| | being created. | | | | established. | |
| | | | | | | |
| "DATA" frame | Carriage of HTTP | Carriage of HTTP response | | Version | Protocol version | Not permitted. Protocol |
| | request/response | message body. | | negotiation | negotiation between | version advertised out of |
| | message body. | | | packet | initiating client | band via Alt-Svc "quic" |
| | | | | | and server. | parameter. |
| "GOAWAY" frame | Early | Prohibited. Use HTTP explicit | | | | |
| | notification (by | session tear-down instead. | | Stateless | Used by a peer to | Not permitted. (Potential |
| | either endpoint) | | | reset | terminate a | denial-of-service attack |
| | of future | | | packet | connection that has | vector.) |
| | connection | | | | become unusable. | |
| | closure, | | | | | |
| | allowing for | | | Short | Used for packets | Used to convey QUIC frames |
| | orderly | | | header | that are sent once | (see below). |
| | completion of | | | packet | a connection has | |
| | open streams. | | | | been established. | |
| | | | | | Used to convey QUIC | |
| "HEADERS" | Carriage of HTTP | Carriage of HTTP response | | | frames (see below). | |
| frame | request/response | message metadata. Trailing | | | | |
| | message | HEADERS frame is permitted. | | Source | Connection IDs | Source Connection ID not |
| | metadata. | | | Connection | negotiated between | used. Destination Connection |
| | Trailing HEADERS | | | ID field, | client and server | ID redefined to be a |
| | frame is | | | Destination | during handshake | Multicast Session ID which is |
| | permitted. | | | Connection | and may be changed | optionally advertised out of |
| | | | | ID field | subsequently using | band via the Alt-Svc |
| "MAX_PUSH_ID" | Used by a | Prohibited. | | | the | "session-id" parameter. May |
| frame | receiver to | | | | "NEW_CONNECTION_ID" | be omitted from packets if |
| | control the | | | | frame. | the address/port tuple is |
| | number of server | | | | | sufficient to identify the |
| | pushes that a | | | | | session, in which case it is |
| | sender can | | | | | not advertised. |
| | initiate. | | +-------------+---------------------+-------------------------------+
| | | |
| "PRIORITY" | Dynamic | Prohibited. |
| frame | adjustment of | |
| | stream priority. | |
| | | |
| "PUSH_PROMISE" | Carriage of HTTP | Carriage of HTTP pseudo- |
| frame | pseudo-request | request message metadata. All |
| | message | HTTP representation transfers |
| | metadata. | over multicast begin this |
| | | way. Stream ID of the first |
| | | client-initiated |
| | | bidirectional stream is |
| | | reserved and all PUSH_PROMISE |
| | | frames reference this as the |
| | | client request from which |
| | | they are notionally derived. |
| | | This stream remains open |
| | | while a sender is |
| | | participating in the |
| | | multicast QUIC session. |
| | | |
| "SETTINGS" | Negotiation of | Prohibited. |
| frame | HTTP/QUIC | |
| | connection | |
| | settings. | |
| | | |
| HTTP/QUIC | | Prohibited. |
| extension | | |
| frames | | |
+----------------+------------------+-------------------------------+
Table 4: HTTP/QUIC Mapping Table 4: QUIC Packet Layer
+------------------------+----------------------+---------------------+
| Protocol feature | Unicast QUIC | Multicast QUIC |
| | | profile |
+------------------------+----------------------+---------------------+
| "PADDING" frame | Used to pad out a | Permitted, but |
| | QUIC packet with | wasteful of network |
| | zero bytes. (The | capacity. |
| | first packet sent on | |
| | a connection must be | |
| | at least 1200 bytes | |
| | long to prove that | |
| | the network can | |
| | transmit packets of | |
| | at least this size.) | |
| | | |
| "PING" frame | Used by an endpoint | Used by the |
| | to verify that its | multicast sender as |
| | peer is still alive. | a session keep- |
| | Acknowledged using a | alive notification. |
| | regular "ACK" frame. | Never acknowledged. |
| | | |
| "ACK" frame | Used by a receiver | Both "ACK" frame |
| | to acknowledge | types are |
| | receipt of data from | prohibited. |
| | its peer. | |
| | | |
| "RESET_STREAM" frame | Request by receiver | Indication to |
| | for sender to | receivers that the |
| | terminate a stream | multicast sender |
| | transmission | has prematurely |
| | prematurely. | terminated a stream |
| | | transmission. |
| | | Prohibited for |
| | | receivers to send. |
| | | |
| "STOP_SENDING" frame | Flow control back | Prohibited. |
| | pressure. Used to | |
| | signal to a peer | |
| | that incoming data | |
| | on a stream is being | |
| | discarded on receipt | |
| | at the application's | |
| | request. This | |
| | abruptly terminates | |
| | a stream. | |
| | | |
| "CRYPTO" frame | Used to transmit | Prohibited. |
| | cryptographic | |
| | handshake messages. | |
| | | |
| "NEW_TOKEN" frame | Used by a server to | Prohibited. Session |
| | supply a token to | migration not |
| | its client to be | currently supported |
| | sent in the header | by this profile. |
| | of an initial packet | |
| | for a future | |
| | connection. Used to | |
| | facilitate | |
| | connection | |
| | migration. | |
| | | |
| "STREAM" frame | Conveys application- | Conveys |
| | layer payloads (see | application-layer |
| | HTTP/3 mapping | payloads (see |
| | below). | HTTP/3 mapping |
| | | below). |
| | | |
| "FIN" bit on "STREAM" | Indication by sender | Indication by the |
| frame | to its peer that a | multicast sender |
| | stream transmission | that a stream |
| | has finished. | transmission has |
| | | finished. |
| | | |
| "MAX_DATA" frame | Flow control update | Prohibited. |
| | notification. | |
| | | |
| "MAX_STREAM_DATA" | Flow control update | Prohibited. |
| frame | notification. | |
| | | |
| "MAX_STREAMS" frame | Used by an endpoint | Prohibited. |
| | to inform a peer of | |
| | the maximum stream | |
| | ID that it is | |
| | permitted to open. | |
| | | |
| "DATA_BLOCKED" frame | Notification to | Prohibited. |
| | receiver that | |
| | sender's | |
| | transmission is | |
| | blocked pending an | |
| | update to its flow | |
| | control window by | |
| | peer. | |
| | | |
| "STREAM_DATA_BLOCKED" | Notification to | Prohibited. |
| frame | receiver that | |
| | sender's | |
| | transmission of a | |
| | single stream is | |
| | blocked pending an | |
| | update to its flow | |
| | control window by | |
| | peer. | |
| | | |
| "STREAMS_BLOCKED" | Notification to | Prohibited. |
| frames | receiver that the | |
| | sender wishes to | |
| | open a stream but is | |
| | unable to do so | |
| | because the maximum | |
| | stream ID has been | |
| | reached for a given | |
| | stream type. | |
| | | |
| "NEW_CONNECTION_ID" | Used to provide a | Prohibited. Session |
| frame | peer with | migration not |
| | alternative | currently supported |
| | connection IDs that | by this profile. |
| | can be used to break | |
| | linkability when | |
| | migrating | |
| | connections. | |
| | | |
| "RETIRE_CONNECTION_ID" | Indicates that an | Prohibited. Session |
| frame | endpoint will no | migration not |
| | longer use a | currently supported |
| | connection ID that | by this profile. |
| | was issued by its | |
| | peer. | |
| | | |
| "PATH_CHALLENGE" frame | Used to check | Prohibited. |
| | reachability to a | |
| | peer and for path | |
| | validation during | |
| | connection | |
| | migration. | |
| | | |
| "PATH_RESPONSE" frame | Sent in response to | Prohibited. |
| | a "PATH_CHALLENGE" | |
| | frame. | |
| | | |
| "CONNECTION_CLOSE" | Notification (by | Prohibited. Use |
| frame | either peer) of | HTTP explicit |
| | graceful connection | session tear-down |
| | shutdown. | instead (see |
| | | Section 5.5). |
+------------------------+----------------------+---------------------+
Table 5: QUIC Framing Layer
+------------------+------------------+-----------------------------+
| Protocol feature | Unicast HTTP/3 | Multicast HTTP/3 profile |
+------------------+------------------+-----------------------------+
| Stream Type | Type of | Only Server Push type is |
| | unidirectional | permitted. |
| | stream. | |
| | | |
| Push ID | Identifies a | Identifies a promised |
| | promised | resource conveyed in an |
| | resource | earlier "PUSH_PROMISE" |
| | conveyed in an | frame. |
| | earlier | |
| | "PUSH_PROMISE" | |
| | frame. | |
| | | |
| "DATA" frame | Carriage of HTTP | Carriage of HTTP response |
| | request/response | message body. |
| | message body. | |
| | | |
| "HEADERS" frame | Carriage of HTTP | Carriage of HTTP response |
| | request/response | message metadata. Trailing |
| | message | "HEADERS" frame is |
| | metadata. | permitted. |
| | Trailing | |
| | "HEADERS" frame | |
| | is permitted. | |
| | | |
| "PRIORITY" frame | Dynamic | Prohibited. |
| | adjustment of | |
| | stream priority. | |
| | | |
| "CANCEL_PUSH" | Used to request | Permitted only for senders. |
| frame | cancellation of | |
| | server push | |
| | prior to the | |
| | push stream | |
| | being created. | |
| | | |
| "SETTINGS" frame | Negotiation of | Prohibited. |
| | HTTP/3 | |
| | connection | |
| | settings. | |
| | | |
| "PUSH_PROMISE" | Carriage of HTTP | Carriage of HTTP pseudo- |
| frame | pseudo-request | request message metadata. |
| | message | All HTTP representation |
| | metadata. | transfers over multicast |
| | | begin this way. Stream ID |
| | | of the first client- |
| | | initiated bidirectional |
| | | stream is reserved and all |
| | | "PUSH_PROMISE" frames |
| | | reference this as the |
| | | client request from which |
| | | they are notionally |
| | | derived. This stream |
| | | remains open while a sender |
| | | is participating in the |
| | | multicast QUIC session. |
| | | |
| "GOAWAY" frame | Early | Prohibited. Use HTTP |
| | notification (by | explicit session tear-down |
| | either endpoint) | instead. |
| | of future | |
| | connection | |
| | closure, | |
| | allowing for | |
| | orderly | |
| | completion of | |
| | open streams. | |
| | | |
| "MAX_PUSH_ID" | Used by a | Prohibited. |
| frame | receiver to | |
| | control the | |
| | number of server | |
| | pushes that a | |
| | sender can | |
| | initiate. | |
| | | |
| "DUPLICATE_PUSH" | Used by servers | Prohibited. |
| frame | to indicate that | |
| | an existing | |
| | pushed resource | |
| | is related to | |
| | multiple client | |
| | requests. | |
| | | |
| "ALTSVC" HTTP/2 | Signalling | Prohibited. |
| extension frame | alternative | |
| | service for | |
| | HTTP/3 session. | |
| | | |
| Other HTTP/2 | | Prohibited. |
| extension frames | | |
+------------------+------------------+-----------------------------+
Table 6: HTTP/3 Mapping
+-------------+----------------------------------+------------------+ +-------------+----------------------------------+------------------+
| Protocol | Unicast HTTP/QUIC | Multicast | | Protocol | Unicast HTTP/3 | Multicast HTTP/3 |
| feature | | HTTP/QUIC | | feature | | profile |
| | | profile |
+-------------+----------------------------------+------------------+ +-------------+----------------------------------+------------------+
| Huffman | Header blocks may use Huffman | Header blocks | | Huffman | Header blocks may use Huffman | Header blocks |
| string | codes to compress literal string | may use Huffman | | string | codes to compress literal string | may use Huffman |
| compression | values. | codes to | | compression | values. | codes to |
| | | compress literal | | | | compress literal |
| | | string values. | | | | string values. |
| | | | | | | |
| Static | Header blocks may refer to | Header blocks | | Static | Header blocks may refer to | Header blocks |
| table | indexed entries in the static | may refer to | | table | indexed entries in the static | may refer to |
| | table. | indexed entries | | | table. | indexed entries |
skipping to change at page 54, line 30 skipping to change at page 59, line 51
| | | table. | | | | table. |
| | | | | | | |
| Dynamic | Header blocks may insert entries | Prohibited, size | | Dynamic | Header blocks may insert entries | Prohibited, size |
| table | into the dynamic table and | is currently | | table | into the dynamic table and | is currently |
| | subsequent header blocks may | locked to 0. | | | subsequent header blocks may | locked to 0. |
| | refer to their indexes. Unused | | | | refer to their indexes. Unused | |
| | as size is currently locked to | | | | as size is currently locked to | |
| | 0. | | | | 0. | |
+-------------+----------------------------------+------------------+ +-------------+----------------------------------+------------------+
Table 5: HTTP Metadata Compression Layer Table 7: HTTP Metadata Compression Layer
Appendix D. Changelog Appendix D. Changelog
*RFC Editor's Note:* Please remove this section prior to *RFC Editor's Note:* Please remove this section prior to
publication of a final version of this document. publication of a final version of this document.
D.1. Since draft-pardue-quic-http-mcast-02 D.1. Since draft-pardue-quic-http-mcast-03
o Update references to QUIC I-Ds.
o Change crypto handshake text now that it's no longer done on
Stream ID 0.
o Update to reference Source and Destination Connection IDs.
o Prohibit the use of connection coalescing, migration and ECN.
o Update allowed and disallowed packets and frames to match the core
specs
o Remove references to the PONG frame (draft-ietf-quic-transport-10)
o Change HTTP/QUIC to HTTP/3 (draft-ietf-quic-http-17)
o Change HPACK to QPACK (draft-ietf-quic-http-10)
o Prohibit the DUPLICATE_PUSH frame
o Clarify packet number space (only use application data space, not
initial or handshake)
o Add statement on QUIC latency spin bit
o Removed sentence stating that multiple Connection IDs cannot be
used concurrently in a unicast QUIC session, in accordance with
[QUIC-TRANSPORT] section 5.1.2.
D.2. Since draft-pardue-quic-http-mcast-02
o No changes. o No changes.
D.2. Since draft-pardue-quic-http-mcast-01 D.3. Since draft-pardue-quic-http-mcast-01
o Explicit guidance on maximum stream ID value permitted. o Explicit guidance on maximum stream ID value permitted.
o Updated guidance on PING (and PONG) frame. o Updated guidance on PING (and PONG) frame.
o Added a comparison table to appendix. o Added a comparison table to appendix.
o Remove invalid use of trailing headers. o Remove invalid use of trailing headers.
o Use the new HTTP/QUIC DATA frame. o Use the new HTTP/QUIC DATA frame.
skipping to change at page 55, line 17 skipping to change at page 61, line 21
o Redefine server push to reflect core document changes. o Redefine server push to reflect core document changes.
o Remove default idle time out value. o Remove default idle time out value.
o Clarify session parameter requirements (session-idle-timeout o Clarify session parameter requirements (session-idle-timeout
became mandatory). became mandatory).
o Update frame notation convention. o Update frame notation convention.
D.3. Since draft-pardue-quic-http-mcast-00 D.4. Since draft-pardue-quic-http-mcast-00
o Update references to QUIC I-Ds. o Update references to QUIC I-Ds.
o Relax session leaving requirements language. o Relax session leaving requirements language.
o Clarify handling of omitted session parameter advertisements. o Clarify handling of omitted session parameter advertisements.
o Rename "Idle" state to "Quiescent". o Rename "Idle" state to "Quiescent".
o Add digest algorithm session parameter. o Add digest algorithm session parameter.
skipping to change at page 55, line 41 skipping to change at page 61, line 45
o Add Initialization Vector session parameter. o Add Initialization Vector session parameter.
o Replace COPT tag-value-pairs with TransportParameter values. o Replace COPT tag-value-pairs with TransportParameter values.
o Add example of an advertisement for a session with content o Add example of an advertisement for a session with content
authenticity and integrity. authenticity and integrity.
Authors' Addresses Authors' Addresses
Lucas Pardue Lucas Pardue
BBC Research & Development
Email: lucas.pardue@bbc.co.uk Email: lucaspardue.24.7@gmail.com
Richard Bradbury Richard Bradbury
BBC Research & Development BBC Research & Development
Email: richard.bradbury@bbc.co.uk Email: richard.bradbury@bbc.co.uk
Sam Hurst
BBC Research & Development
Email: sam.hurst@bbc.co.uk
 End of changes. 135 change blocks. 
625 lines changed or deleted 913 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/