< draft-pardue-quic-http-mcast-01.txt   draft-pardue-quic-http-mcast-02.txt >
Network Working Group L. Pardue Network Working Group L. Pardue
Internet-Draft R. Bradbury Internet-Draft R. Bradbury
Intended status: Informational BBC Research & Development Intended status: Informational BBC Research & Development
Expires: February 12, 2018 August 11, 2017 Expires: August 6, 2018 February 2, 2018
Hypertext Transfer Protocol (HTTP) over multicast QUIC Hypertext Transfer Protocol (HTTP) over multicast QUIC
draft-pardue-quic-http-mcast-01 draft-pardue-quic-http-mcast-02
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/
QUIC mapping that facilitates the transfer of HTTP resources over QUIC 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.
skipping to change at page 1, line 35 skipping to change at page 1, line 35
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 12, 2018. This Internet-Draft will expire on August 6, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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 . . . . . . . . . . . . . . . . . 5 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 6
1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 6 1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 6
2. Multicast QUIC Sessions . . . . . . . . . . . . . . . . . . . 6 2. Multicast QUIC Sessions . . . . . . . . . . . . . . . . . . . 7
2.1. Session States . . . . . . . . . . . . . . . . . . . . . 7 2.1. Session States . . . . . . . . . . . . . . . . . . . . . 7
2.1.1. Session Establishment . . . . . . . . . . . . . . . . 8 2.1.1. Session Establishment . . . . . . . . . . . . . . . . 8
2.1.2. Session Termination . . . . . . . . . . . . . . . . . 8 2.1.2. Session Termination . . . . . . . . . . . . . . . . . 8
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 . . . . . . . . . . . . . . . . . 9 2.3. Session Identification . . . . . . . . . . . . . . . . . 10
2.4. Session Security . . . . . . . . . . . . . . . . . . . . 10 2.4. Session Security . . . . . . . . . . . . . . . . . . . . 10
3. Session Advertisement . . . . . . . . . . . . . . . . . . . . 10 3. Session Advertisement . . . . . . . . . . . . . . . . . . . . 11
3.1. Version Advertisement . . . . . . . . . . . . . . . . . . 11 3.1. Version Advertisement . . . . . . . . . . . . . . . . . . 11
3.2. Security Context . . . . . . . . . . . . . . . . . . . . 12 3.2. Security Context . . . . . . . . . . . . . . . . . . . . 12
3.3. Session Identification . . . . . . . . . . . . . . . . . 12 3.2.1. Cipher Suite . . . . . . . . . . . . . . . . . . . . 12
3.2.2. Key Exchange . . . . . . . . . . . . . . . . . . . . 13
3.2.3. Initialization Vector . . . . . . . . . . . . . . . . 13
3.3. Session Identification . . . . . . . . . . . . . . . . . 13
3.4. Session Idle Timeout . . . . . . . . . . . . . . . . . . 13 3.4. Session Idle Timeout . . . . . . . . . . . . . . . . . . 13
3.5. Session Peak Flow Rate . . . . . . . . . . . . . . . . . 13 3.5. Session Peak Flow Rate . . . . . . . . . . . . . . . . . 14
3.6. Resource Concurrency . . . . . . . . . . . . . . . . . . 13 3.6. Resource Concurrency . . . . . . . . . . . . . . . . . . 14
3.7. Additional TransportParameter Considerations . . . . . . 14 3.7. Additional TransportParameter Considerations . . . . . . 15
3.8. Digest Algorithm . . . . . . . . . . . . . . . . . . . . 14 3.8. Digest Algorithm . . . . . . . . . . . . . . . . . . . . 15
3.9. Signature Algorithm . . . . . . . . . . . . . . . . . . . 15 3.9. Signature Algorithm . . . . . . . . . . . . . . . . . . . 16
4. QUIC Profile . . . . . . . . . . . . . . . . . . . . . . . . 16 4. QUIC Profile . . . . . . . . . . . . . . . . . . . . . . . . 17
4.1. Packet Size . . . . . . . . . . . . . . . . . . . . . . . 16 4.1. Packet Size . . . . . . . . . . . . . . . . . . . . . . . 17
4.2. Version Negotiation . . . . . . . . . . . . . . . . . . . 16 4.2. Packet Format . . . . . . . . . . . . . . . . . . . . . . 17
4.3. Connection Identifier . . . . . . . . . . . . . . . . . . 17 4.3. Connection Identifier . . . . . . . . . . . . . . . . . . 18
4.4. Stream Identifier . . . . . . . . . . . . . . . . . . . . 17 4.4. Stream Identifier . . . . . . . . . . . . . . . . . . . . 18
4.5. Flow Control . . . . . . . . . . . . . . . . . . . . . . 17 4.5. Flow Control . . . . . . . . . . . . . . . . . . . . . . 18
4.6. Stream Termination . . . . . . . . . . . . . . . . . . . 17 4.6. Stream Termination . . . . . . . . . . . . . . . . . . . 18
4.7. Session Shutdown . . . . . . . . . . . . . . . . . . . . 17 4.7. Session Shutdown . . . . . . . . . . . . . . . . . . . . 19
4.8. Session Keep-alive . . . . . . . . . . . . . . . . . . . 18 4.8. Session Keep-alive . . . . . . . . . . . . . . . . . . . 19
4.9. Loss Detection and Recovery . . . . . . . . . . . . . . . 18 4.9. Loss Detection and Recovery . . . . . . . . . . . . . . . 19
4.10. Prohibited QUIC Frames and Packets . . . . . . . . . . . 18 4.10. Prohibited QUIC Frames and Packets . . . . . . . . . . . 20
5. HTTP/QUIC Profile . . . . . . . . . . . . . . . . . . . . . . 19 5. HTTP/QUIC Profile . . . . . . . . . . . . . . . . . . . . . . 20
5.1. HTTP Connection Settings . . . . . . . . . . . . . . . . 19 5.1. HTTP Connection Settings . . . . . . . . . . . . . . . . 20
5.2. Server Push . . . . . . . . . . . . . . . . . . . . . . . 19 5.2. Server Push . . . . . . . . . . . . . . . . . . . . . . . 21
5.3. Metadata Compression . . . . . . . . . . . . . . . . . . 20 5.3. Metadata Compression . . . . . . . . . . . . . . . . . . 21
5.4. Prioritisation . . . . . . . . . . . . . . . . . . . . . 20 5.4. Prioritisation . . . . . . . . . . . . . . . . . . . . . 22
5.5. Session Tear-down . . . . . . . . . . . . . . . . . . . . 20 5.5. Session Tear-down . . . . . . . . . . . . . . . . . . . . 22
5.6. HTTP/2 Extension frames . . . . . . . . . . . . . . . . . 20 5.6. HTTP/QUIC Extension frames . . . . . . . . . . . . . . . 22
5.7. Prohibited HTTP/2 Frames . . . . . . . . . . . . . . . . 21 5.7. Prohibited HTTP/QUIC Frames . . . . . . . . . . . . . . . 22
6. Application-Layer Security . . . . . . . . . . . . . . . . . 21
6.1. Content Integrity . . . . . . . . . . . . . . . . . . . . 21 6. Application-Layer Security . . . . . . . . . . . . . . . . . 23
6.2. Content Authenticity . . . . . . . . . . . . . . . . . . 22 6.1. Content Integrity . . . . . . . . . . . . . . . . . . . . 23
6.3. Content Confidentiality . . . . . . . . . . . . . . . . . 23 6.2. Content Authenticity . . . . . . . . . . . . . . . . . . 23
7. Loss Recovery . . . . . . . . . . . . . . . . . . . . . . . . 23 6.3. Content Confidentiality . . . . . . . . . . . . . . . . . 25
7.1. Forward Error Correction . . . . . . . . . . . . . . . . 23 7. Loss Recovery . . . . . . . . . . . . . . . . . . . . . . . . 25
7.2. Unicast Repair . . . . . . . . . . . . . . . . . . . . . 24 7.1. Forward Error Correction . . . . . . . . . . . . . . . . 25
8. Transmission of Partial Content . . . . . . . . . . . . . . . 24 7.2. Unicast Repair . . . . . . . . . . . . . . . . . . . . . 25
9. Protocol Identifier . . . . . . . . . . . . . . . . . . . . . 25 8. Transmission of Partial Content . . . . . . . . . . . . . . . 26
9.1. Draft Version Identification . . . . . . . . . . . . . . 25 9. Protocol Identifier . . . . . . . . . . . . . . . . . . . . . 26
10. Discovery of Multicast QUIC Sessions . . . . . . . . . . . . 25 9.1. Draft Version Identification . . . . . . . . . . . . . . 26
10.1. Source-specific Multicast Advertisement . . . . . . . . 26 10. Discovery of Multicast QUIC Sessions . . . . . . . . . . . . 27
10.2. Session Parameter Advertisement . . . . . . . . . . . . 27 10.1. Source-specific Multicast Advertisement . . . . . . . . 28
10.2.1. Version . . . . . . . . . . . . . . . . . . . . . . 27 10.2. Session Parameter Advertisement . . . . . . . . . . . . 28
10.2.2. Cipher Suite . . . . . . . . . . . . . . . . . . . . 27 10.2.1. Version . . . . . . . . . . . . . . . . . . . . . . 28
10.2.3. Session Key . . . . . . . . . . . . . . . . . . . . 27 10.2.2. Cipher Suite . . . . . . . . . . . . . . . . . . . . 28
10.2.4. Session Cipher Initialization Vector . . . . . . . . 28 10.2.3. Session Key . . . . . . . . . . . . . . . . . . . . 29
10.2.5. Session Identification . . . . . . . . . . . . . . . 28 10.2.4. Session Cipher Initialization Vector . . . . . . . . 29
10.2.6. Session Idle Timeout Period . . . . . . . . . . . . 28 10.2.5. Session Identification . . . . . . . . . . . . . . . 29
10.2.7. Resource Concurrency . . . . . . . . . . . . . . . . 29 10.2.6. Session Idle Timeout Period . . . . . . . . . . . . 30
10.2.8. Session Peak Flow Rate . . . . . . . . . . . . . . . 29 10.2.7. Resource Concurrency . . . . . . . . . . . . . . . . 30
10.2.9. Digest Algorithm . . . . . . . . . . . . . . . . . . 29 10.2.8. Session Peak Flow Rate . . . . . . . . . . . . . . . 30
10.2.10. Signature Algorithm . . . . . . . . . . . . . . . . 30 10.2.9. Digest Algorithm . . . . . . . . . . . . . . . . . . 31
11. Security and Privacy Considerations . . . . . . . . . . . . . 30 10.2.10. Signature Algorithm . . . . . . . . . . . . . . . . 31
11.1. Pervasive Monitoring . . . . . . . . . . . . . . . . . . 31 11. Security and Privacy Considerations . . . . . . . . . . . . . 32
11.1.1. Large-scale Data Gathering and Correlation . . . . . 31 11.1. Pervasive Monitoring . . . . . . . . . . . . . . . . . . 32
11.1.2. Changing Content . . . . . . . . . . . . . . . . . . 31 11.1.1. Large-scale Data Gathering and Correlation . . . . . 32
11.2. Protection of Discovery Mechanism . . . . . . . . . . . 32 11.1.2. Changing Content . . . . . . . . . . . . . . . . . . 33
11.3. Spoofing . . . . . . . . . . . . . . . . . . . . . . . . 32 11.2. Protection of Discovery Mechanism . . . . . . . . . . . 33
11.3.1. Spoofed Ack Attacks . . . . . . . . . . . . . . . . 32 11.3. Spoofing . . . . . . . . . . . . . . . . . . . . . . . . 33
11.3.2. Sender Spoofing . . . . . . . . . . . . . . . . . . 32 11.3.1. Spoofed Ack Attacks . . . . . . . . . . . . . . . . 33
11.3.3. Receiver Spoofing . . . . . . . . . . . . . . . . . 32 11.3.2. Sender Spoofing . . . . . . . . . . . . . . . . . . 33
11.4. Replay Attacks . . . . . . . . . . . . . . . . . . . . . 33 11.3.3. Receiver Spoofing . . . . . . . . . . . . . . . . . 34
11.5. Message Deletion . . . . . . . . . . . . . . . . . . . . 33 11.4. Replay Attacks . . . . . . . . . . . . . . . . . . . . . 34
11.6. Denial of Service . . . . . . . . . . . . . . . . . . . 33 11.5. Message Deletion . . . . . . . . . . . . . . . . . . . . 34
11.6.1. Unprotected Frames and Packets . . . . . . . . . . . 33 11.6. Denial of Service . . . . . . . . . . . . . . . . . . . 34
11.6.2. Network Performance Degradation . . . . . . . . . . 34 11.6.1. Unprotected Frames and Packets . . . . . . . . . . . 35
11.6.3. Unicast Repair Stampeding Herd . . . . . . . . . . . 34 11.6.2. Network Performance Degradation . . . . . . . . . . 35
11.7. Receiver Resource Usage . . . . . . . . . . . . . . . . 34 11.6.3. Unicast Repair Stampeding Herd . . . . . . . . . . . 35
11.8. Unicast Repair Information Leakage . . . . . . . . . . . 34 11.7. Receiver Resource Usage . . . . . . . . . . . . . . . . 35
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 11.8. Unicast Repair Information Leakage . . . . . . . . . . . 35
12.1. Registration of Protocol Identification String . . . . . 35 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36
12.2. Registration of Alt-Svc parameters . . . . . . . . . . . 35 12.1. Registration of Protocol Identification String . . . . . 36
12.2.1. Source Address . . . . . . . . . . . . . . . . . . . 35 12.2. Registration of Alt-Svc parameters . . . . . . . . . . . 36
12.2.2. Cipher Suite . . . . . . . . . . . . . . . . . . . . 35 12.2.1. Source Address . . . . . . . . . . . . . . . . . . . 37
12.2.3. Key . . . . . . . . . . . . . . . . . . . . . . . . 36 12.2.2. Cipher Suite . . . . . . . . . . . . . . . . . . . . 37
12.2.4. Initialization Vector . . . . . . . . . . . . . . . 36 12.2.3. Key . . . . . . . . . . . . . . . . . . . . . . . . 37
12.2.5. Session Identifier . . . . . . . . . . . . . . . . . 36 12.2.4. Initialization Vector . . . . . . . . . . . . . . . 37
12.2.6. Session Idle Timeout . . . . . . . . . . . . . . . . 36 12.2.5. Session Identifier . . . . . . . . . . . . . . . . . 37
12.2.7. Maximum Concurrent Resources . . . . . . . . . . . . 36 12.2.6. Session Idle Timeout . . . . . . . . . . . . . . . . 37
12.2.8. Peak Flow Rate . . . . . . . . . . . . . . . . . . . 36 12.2.7. Maximum Concurrent Resources . . . . . . . . . . . . 37
12.2.9. Digest Algorithm . . . . . . . . . . . . . . . . . . 36 12.2.8. Peak Flow Rate . . . . . . . . . . . . . . . . . . . 38
12.2.10. Signature Algorithm . . . . . . . . . . . . . . . . 36 12.2.9. Digest Algorithm . . . . . . . . . . . . . . . . . . 38
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 12.2.10. Signature Algorithm . . . . . . . . . . . . . . . . 38
13.1. Normative References . . . . . . . . . . . . . . . . . . 37 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 38
13.2. Informative References . . . . . . . . . . . . . . . . . 38 13.1. Normative References . . . . . . . . . . . . . . . . . . 38
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 40 13.2. Informative References . . . . . . . . . . . . . . . . . 39
Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 40 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 41
B.1. Session Advertisement . . . . . . . . . . . . . . . . . . 40 Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 42
B.1.1. Source-specific Multicast QUIC Session . . . . . . . 40 B.1. Session Advertisement . . . . . . . . . . . . . . . . . . 42
B.1.1. Source-specific Multicast QUIC Session . . . . . . . 42
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 . . . . . . . . . . 41 Encryption using a Symmetric Key . . . . . . . . . . 42
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 . . . 41 Encryption, Content Integrity and Authenticity . . . 43
B.2. Resource Transfer . . . . . . . . . . . . . . . . . . . . 42 B.2. Resource Transfer . . . . . . . . . . . . . . . . . . . . 43
B.2.1. Transfer without Content Integrity or Authenticity . 42 B.2.1. Transfer without Content Integrity or Authenticity . 43
B.2.2. Transfer of Partial Content without Content Integrity B.2.2. Transfer of Partial Content without Content Integrity
or Authenticity . . . . . . . . . . . . . . . . . . . 42 or Authenticity . . . . . . . . . . . . . . . . . . . 44
B.2.3. Transfer with Content Integrity and without B.2.3. Transfer with Content Integrity and without
Authenticity . . . . . . . . . . . . . . . . . . . . 43
B.2.4. Partial Transfer with Content Integrity and without
Authenticity . . . . . . . . . . . . . . . . . . . . 44 Authenticity . . . . . . . . . . . . . . . . . . . . 44
B.2.5. Transfer with Content Integrity and Authenticity . . 44 B.2.4. Partial Transfer with Content Integrity and without
B.2.6. Partial Transfer with Content Integrity and
Authenticity . . . . . . . . . . . . . . . . . . . . 45 Authenticity . . . . . . . . . . . . . . . . . . . . 45
Appendix C. Changelog . . . . . . . . . . . . . . . . . . . . . 46 B.2.5. Transfer with Content Integrity and Authenticity . . 45
C.1. Since draft-pardue-quic-http-mcast-00 . . . . . . . . . . 46 B.2.6. Partial Transfer with Content Integrity and
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47 Authenticity . . . . . . . . . . . . . . . . . . . . 46
Appendix C. Summary of differences from unicast QUIC and
HTTP/QUIC . . . . . . . . . . . . . . . . . . . . . 47
Appendix D. Changelog . . . . . . . . . . . . . . . . . . . . . 54
D.1. Since draft-pardue-quic-http-mcast-01 . . . . . . . . . . 54
D.2. Since draft-pardue-quic-http-mcast-00 . . . . . . . . . . 55
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 55
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.
skipping to change at page 5, line 10 skipping to change at page 5, line 16
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/QUIC 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 compatibility with conventional QUIC.
For the reader's convenience, the 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 5, line 47 skipping to change at page 6, line 8
connection establishment aspects that depend on a bidirectional connection establishment aspects that depend on a bidirectional
transport. transport.
The present document includes a number of optional features. It is The present document includes a number of optional features. It is
anticipated that further specifications will define interoperability anticipated that further specifications will define interoperability
profiles suited to particular application domains. profiles suited to particular application domains.
1.1. Notational Conventions 1.1. Notational Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in [RFC2119]. "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
captials, as shown here.
This document uses the Augmented BNF defined in [RFC5234] and updated This document uses the Augmented BNF defined in [RFC5234] and updated
by [RFC7405] along with the "#rule" extension defined in Section 7 of by [RFC7405] along with the "#rule" extension defined in Section 7 of
[RFC7230]. The rules below are defined in [RFC5234], [RFC7230], and [RFC7230]. The rules below are defined in [RFC5234], [RFC7230], and
[RFC7234]: [RFC7234]:
o quoted-string = <quoted-string, see [RFC7230], Section 3.2.6> o quoted-string = <quoted-string, see [RFC7230], Section 3.2.6>
o token = <token, see [RFC7230], Section 3.2.6> o token = <token, see [RFC7230], Section 3.2.6>
o uri-host = <uri-host, see [RFC7230], Section 2.7> o uri-host = <uri-host, see [RFC7230], Section 2.7>
1.2. Definitions 1.2. Definitions
skipping to change at page 7, line 4 skipping to change at page 7, line 17
An HTTP/QUIC connection [QUIC-TRANSPORT] carried over bidirectional An HTTP/QUIC connection [QUIC-TRANSPORT] carried over bidirectional
unicast is defined as a conversation between two QUIC endpoints that unicast 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 Connection ID. Use of a consistent connection
identifier allows QUIC connections to survive changes to the network 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 "SETTINGS" HTTP/2 messages) and HTTP-specific settings (conveyed in HTTP/QUIC
frames). Such parameters may be required or optional and may be used "SETTINGS" frames). Such parameters may be required or optional and
by either endpoint to control the characteristics of connection may be used by either endpoint to control the characteristics of
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/QUIC
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
skipping to change at page 10, line 22 skipping to change at page 10, line 36
Section 10.2) before any HTTP-level processing is done. In the case Section 10.2) before any HTTP-level processing is done. In the case
of validation failure, the receiver SHOULD ignore the packet in order of validation failure, the receiver SHOULD ignore the packet in order
to protect itself from denial-of-service attacks. 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 Crypto and Transport handshake (see [QUIC-TRANSPORT], The QUIC cryptographic handshake ([QUIC-TRANSPORT] and [QUIC-TLS])
[QUIC-TLS] and [QUICCrypto]) sets out methods to achieve the goals of sets out methods to achieve the goals of authenticated key exchange
authenticated key exchange and record protection between two and QUIC packet protection between two endpoints forming a QUIC
endpoints forming a QUIC connection. The design facilitates low- connection. The design facilitates low-latency connection; 1-RTT or
latency connection; 1-RTT or 0-RTT. The Crypto handshake [QUIC-TLS] 0-RTT. QUIC Stream 0 is reserved for handshake messages.
reserves QUIC stream 0 for TLS handshake messages.
This specification replaces the in-band security handshake, achieving This specification replaces the in-band security handshake, achieving
similar goals through the use of session parameters described in similar goals through the use of session parameters described in
Section 3.2. For the purpose of compatibility, the use of QUIC Section 3.2. For the purpose of compatibility, the use of QUIC
stream 0 (see Section 4.4) is reserved. 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
skipping to change at page 11, line 12 skipping to change at page 11, line 25
Appendix B.1. QUIC connection parameters not defined as, or related Appendix B.1. QUIC connection parameters not defined as, or related
to, Alt-Svc parameters are not used. to, Alt-Svc parameters are not used.
The definition of a session (including the session ID and its The definition of a session (including the session ID and its
parameters) is not the responsibility of any endpoint. Rather, parameters) is not the responsibility of any endpoint. Rather,
endpoints SHOULD use session advertisements to determine if they are endpoints SHOULD use session advertisements to determine if they are
capable of participating in a given session. This document does not capable of participating in a given session. This document does not
specify which party is responsible for defining and/or advertising specify which party is responsible for defining and/or advertising
multicast QUIC sessions. multicast QUIC sessions.
Endpoints SHOULD NOT become participants in sessions where the
advertisement requirements set out in the present document are
unfulfilled.
The freshness of Alt-Svc multicast QUIC session advertisements is as The freshness of Alt-Svc multicast QUIC session advertisements is as
described in section 2.2 of [RFC7838]. described in section 2.2 of [RFC7838].
It is RECOMMENDED that session advertisements are carried over a It is RECOMMENDED that session advertisements are carried over a
secure transport (such as HTTPS) which can guarantee the authenticity secure transport (such as HTTPS) which can guarantee the authenticity
and integrity of the Alt-Svc information. This addresses some of the and integrity of the Alt-Svc information. This addresses some of the
concerns around the protection of session establishment described in concerns around the protection of session establishment described in
Section 11.2. Section 11.2.
*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 11, line 38 skipping to change at page 12, line 7
*Authors' Note:* Version negotiation (as described in WG *Authors' Note:* Version negotiation (as described in WG
documents) is in flux. This section will track developments and documents) is in flux. This section will track developments and
will be updated accordingly. will be updated accordingly.
Conventional QUIC connection establishment begins with version Conventional QUIC connection establishment begins with version
negotiation. In a unidirectional multicast environment, there is no negotiation. In a unidirectional multicast environment, there is no
reasonable way to negotiate in such a manner. [QUIC-HTTP] defines an reasonable way to negotiate in such a manner. [QUIC-HTTP] defines an
Alt-Svc "quic" parameter that can be advertised to clients for use as Alt-Svc "quic" parameter that can be advertised to clients for use as
a version negotiation hint. This specification uses "quic" as a a version negotiation hint. This specification uses "quic" as a
session parameter for a similar purpose but with the additional session parameter for a similar purpose. This mechanism replaces the
constraint that the parameter MUST appear exactly once: it is not use of the Version field in the QUIC packet long header (see
optional and the parameter MUST NOT be repeated. Section 4.2).
This mechanism replaces the use of the Version field in the QUIC The Alt-Svc "quic" parameter is mandatory. Session advertisements
packet long header (see Section 4.2). MUST contain exactly one instance of it and it MUST NOT be repeated.
A multicast sender participating in a session MUST send QUIC packets A multicast sender participating in a session MUST send QUIC packets
and frames in the format corresponding to the advertised version. If and frames in the format corresponding to the advertised version. If
the sender does not support the advertised version it MUST NOT send the sender does not support the advertised version it MUST NOT send
any data. A receiver MUST NOT join a session where the "quic" any data. A receiver MUST NOT join a session where the "quic"
parameter is absent. A receiver SHOULD NOT join a session for which parameter is absent. A receiver SHOULD NOT join a session for which
it does not support the advertised version, in order to avoid wasting it does not support the advertised version, in order to avoid wasting
processing resources. processing resources.
3.2. Security Context 3.2. Security Context
*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.
This specification replaces the in-band security handshake: This specification replaces the in-band security handshake. The
session parameters "cipher suite", "key" and "iv" (described below)
allow for the establishment of a security context. In order to
protect themselves, endpoints SHOULD NOT participate in sessions for
which they cannot establish reasonable confidence over the cipher
suite, key, or IV in use for that session. Endpoints SHOULD leave
any sessions which fail to successfully match anticipated security
characteristics.
o Cipher suite negotiation is replaced with a "cipher suite" session 3.2.1. Cipher Suite
parameter, which is advertised as the Alt-Svc parameter "cipher-
suite" (Section 10.2.2). If present, this parameter MUST contain
only one value that corresponds to an entry in the TLS Cipher
Suite Registry (see http://www.iana.org/assignments/tls-
parameters/tls-parameters.xhtml#tls-parameters-4). If absent, the
multicast QUIC session is assumed to be operating with cipher
suite 0x00,0x00 (NULL_WITH_NULL_NULL).
o Key exchange is replaced with a "key" session parameter, which is Cipher suite negotiation is replaced with a "cipher suite" session
advertised as the Alt-Svc parameter "key" (Section 10.2.3). The parameter, which is advertised as the Alt-Svc parameter "cipher-
parameter carries a variable-length hex-encoded key for use with suite" (Section 10.2.2).
the session cipher suite. In the absence of the "key" parameter,
the key may be available via an out-of-band method not described
in this document.
o Initialization Vector (IV) exchange is replaced with an "iv" The Alt-Svc "cipher-suite" parameter is OPTIONAL. If present, this
session parameter, which is advertised as the Alt-Svc parameter parameter MUST contain only one value that corresponds to an entry in
"iv" (Section 10.2.4). The parameter carries a variable-length the TLS Cipher Suite Registry (see http://www.iana.org/assignments/
hex-encoded IV for use with the session cipher suite and key. In tls-parameters/tls-parameters.xhtml#tls-parameters-4). Session
the absence of the "iv" parameter, the IV may be available via an advertisments that omit this parameter imply that the session is
out-of-band method not described in this document. operating with cipher suite 0x00,0x00 (NULL_WITH_NULL_NULL).
In order to protect themselves, endpoints SHOULD NOT participate in 3.2.2. Key Exchange
sessions for which they cannot establish reasonable confidence over
the cipher suite or key in use for that session. Endpoints SHOULD Key exchange is replaced with a "key" session parameter, which is
leave any sessions which fail to successfully match anticipated advertised as the Alt-Svc parameter "key" (Section 10.2.3). The
security characteristics. parameter carries a variable-length hex-encoded key for use with the
session cipher suite.
The Alt-Svc "key" parameter is OPTIONAL. Session advertisments that
omit this parameter imply that the key may be available via an out-
of-band method not described in this document.
3.2.3. Initialization Vector
Initialization Vector (IV) exchange is replaced with an "iv" session
parameter, which is advertised as the Alt-Svc parameter "iv"
(Section 10.2.4). The parameter carries a variable-length hex-
encoded IV for use with the session cipher suite and key.
The Alt-Svc "iv" parameter is OPTIONAL. Session advertisments that
omit this parameter imply that the IV may be available via an out-of-
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 ID is used, in
particular the client-side generation of this value. In a particular the client-side generation of this value. In a
unidirectional multicast environment, there is no meaningful way for unidirectional multicast environment, there is no meaningful way for
a client to generate a Connection ID and use it. This document a client to generate a Connection ID and use it. This document
defines a "session identifier" session parameter, which is advertised defines a "session identifier" session parameter, which is advertised
as the Alt-Svc parameter "session-id" (Section 10.2.5). The as the Alt-Svc parameter "session-id" (Section 10.2.5). The
requirements for the usage of session identifiers have already been requirements for the usage of session identifiers have already been
described in Section 2.3. described in Section 2.3.
The Alt-Svc "session-id" parameter is mandatory. Session
advertisments MUST contain at least one instance. It MAY be repeated
with different values, indicating that multiple sessions are present.
*Authors' Note:* We invite review comments on mandating a single
session identifier per advertised session, i.e. only one session
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 required 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 advertisements that omit the Alt-Svc parameter "session-idle- Session idle timeout may be prevented by keep-alive strategies
timeout" imply that the default timeout period is in use. The Section 4.8.
default value is 30 seconds.
The Alt-Svc "session-idle-timeout" parameter is mandatory. Session
advertisments MUST contain at least one instance. If the parameter
is repeated the first occurrence MUST be used and subsequent
occurrences MUST be ignored.
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 participants MUST use the silent close method, in which no QUIC
"CONNECTION_CLOSE" QUIC 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. Window size connection parameters are
exchanged on connection establishment using the required QUIC exchanged on connection establishment using the required QUIC
TransportParameters "initial_max_data" and "initial_max_stream_data". TransportParameters "initial_max_data" and "initial_max_stream_data".
In a unidirectional multicast environment, such a scheme is In a unidirectional multicast environment, such a scheme is
infeasible. This document defines a "peak flow rate" session infeasible. This document defines a "peak flow rate" session
parameter, expressed in units of bits per second, which is advertised parameter, expressed in units of bits per second, which is advertised
as the Alt-Svc parameter "peak-flow-rate" (Section 10.2.8). This as the Alt-Svc parameter "peak-flow-rate" (Section 10.2.8). This
replaces "initial_max_data" and "initial_max_stream_data" completely, replaces "initial_max_data" and "initial_max_stream_data" completely,
instead indicating the maximum bit rate of "STREAM" QUIC frame instead indicating the maximum bit rate of QUIC "STREAM" frame
payloads transmitted on all multicast groups comprising the session. payloads transmitted on all multicast groups comprising the session.
Session advertisements that omit the Alt-Svc parameter "peak-flow- The Alt-Svc "peak-flow-rate" parameter is OPTIONAL. If the parameter
rate" imply that the flow rate is unlimited. is repeated the first occurrence MUST be used and subsequent
occurrences MUST be ignored. Session advertisements that omit the
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 required QUIC TransportParameter ID is controlled by the relevant required QUIC TransportParameters
"initial_max_stream_id". It is increased during the lifetime of a "initial_max_stream_id_bidi" and "initial_max_stream_id_uni". They
QUIC connection by the "MAX_STREAM_ID" QUIC frame. In a are increased during the lifetime of a QUIC connection by the QUIC
unidirectional multicast environment, there is no way for a receiver "MAX_STREAM_ID" frame. In a unidirectional multicast environment,
to specify the limit nor increase it. Therefore the maximum stream there is no way for a receiver to specify an initial limit nor
ID mechanism is not used to manage concurrency in multicast QUIC. increase it. Therefore in multicast QUIC, the maximum Stream ID
The "STREAM_ID_NEEDED" QUIC frame MAY be sent by a sending (initial and always) is 2^62. This mechanism is not used to manage
participant but it will have no effect. This frame SHALL be ignored concurrency in multicast QUIC.
by receiving participants.
Due to the profiling of maximum Stream ID, there is no role for the
QUIC "STREAM_ID_BLOCKED" frame and it is prohibited. Participants
MUST NOT send this frame type. Reception of this frame type MUST be
handled as described in Section 4.10.
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". It advertises the maximum number of "initial_max_stream_id_bidi" and "initial_max_stream_id_uni". It
concurrent active resources generated by a sender in a given advertises the maximum number of concurrent active resources
multicast QUIC session. generated by a sender in a given multicast QUIC session.
Session advertisements that omit the Alt-Svc parameter "maximum The Alt-Svc "max-concurrent-resources" parameter is OPTIONAL. If the
concurrent resources" imply that the maximum concurrency is parameter is repeated the first occurrence MUST be used and
unlimited. subsequent occurrences MUST be ignored. Session advertisements that
omit the parameter imply that the maximum concurrency is unlimited.
A multicast sender participating in a session MUST NOT cause the A multicast sender participating in a session MUST NOT cause the
advertised "max-concurrent-resources" to be exceeded. A receiver MAY advertised "max-concurrent-resources" to be exceeded. A receiver MAY
leave any session where the advertised limit is exceeded, in order to leave any session where the advertised limit is exceeded, in order to
protect itself from denial-of-service attacks. protect itself from denial-of-service attacks.
3.7. Additional TransportParameter Considerations 3.7. Additional TransportParameter Considerations
*Authors' Note:* Google QUIC Connection Options (COPTs) are no *Authors' Note:* This section will consider TransportParameters
longer referred to in WG documents. This section will consider that have not already been addressed, as required. It will track
TransportParameters, tracking developments and issues that may developments and issues that may arise.
arise.
3.8. Digest Algorithm 3.8. Digest Algorithm
A method to provide content integrity is described in Section 6.1. A method to provide content integrity is described in Section 6.1.
This specifies the means to convey a value computed by a particular This specifies the means to convey a value computed by a particular
digest algorithm. The identity of the selected algorithm is also digest algorithm. The identity of the selected algorithm is also
indicated. Valid digest algorithms are collected in the IANA HTTP indicated. Valid digest algorithms are collected in the IANA HTTP
Digest Algorithm Values registry (http://www.iana.org/assignments/ Digest Algorithm Values registry (http://www.iana.org/assignments/
http-dig-alg/http-dig-alg.xhtml#http-dig-alg-1). http-dig-alg/http-dig-alg.xhtml#http-dig-alg-1).
This document specifies a "digest algorithm" session parameter, which This document specifies a "digest algorithm" session parameter, which
is advertised as the Alt-Svc parameter "digest-algorithm" is advertised as the Alt-Svc parameter "digest-algorithm"
(Section 10.2.9). (Section 10.2.9).
*Authors' Note:* Section 6.1 contains an author's note on the *Authors' Note:* Section 6.1 contains an author's note on the
potential for content integrity to become mandatory. This section potential for content integrity to become mandatory. This section
will be updated in line with the outcome of that decision. will be updated in line with the outcome of that decision.
Repetition of the "digest algorithm" parameter in a single The Alt-Svc "digest-algorithm" parameter is OPTIONAL. Repetition of
advertisement describes an algorithm set that MAY be used across the the "digest algorithm" parameter in a single advertisement describes
session. Session advertisements that omit the Alt-Svc parameter an algorithm set that MAY be used across the session. Session
"digest-algorithm" imply that either: advertisements that omit the Alt-Svc parameter "digest-algorithm"
imply that either:
o the session does not use the content integrity mechanism, or o the session does not use the content integrity mechanism, or
o the algorithm set is unrestricted, i.e. a sender may vary the o the algorithm set is unrestricted, i.e. a sender may vary the
algorithm as it so chooses. This may lead to undesirable results algorithm as it so chooses. This may lead to undesirable results
if receivers do not support a chosen algorithm. if receivers do not support a chosen algorithm.
Advertising the algorithm set for a session gives receivers the Advertising the algorithm set for a session gives receivers the
opportunity to selectively join sessions where the algorithms are opportunity to selectively join sessions where the algorithms are
known to be supported. This may help to mitigate latency issues in known to be supported. This may help to mitigate latency issues in
skipping to change at page 15, line 43 skipping to change at page 16, line 48
signature-algorithms). signature-algorithms).
This document specifies a "signature algorithm" session parameter, This document specifies a "signature algorithm" session parameter,
which is advertised as the Alt-Svc parameter "signature-algorithm" which is advertised as the Alt-Svc parameter "signature-algorithm"
(Section 10.2.10). (Section 10.2.10).
*Authors' Note:* Section 6.2 contains an author's note on the *Authors' Note:* Section 6.2 contains an author's note on the
potential for content authenticity to become mandatory. This potential for content authenticity to become mandatory. This
section will be updated in line with the outcome of that decision. section will be updated in line with the outcome of that decision.
Repetition of the "signature algorithm" parameter in a single The Alt-Svc "signature-algorithm" parameter is OPTIONAL. Repetition
advertisement describes an algorithm set that MAY be used across the of the "signature algorithm" parameter in a single advertisement
session. Session advertisements that omit the Alt-Svc parameter describes an algorithm set that MAY be used across the session.
"signature-algorithm" imply that either: Session advertisements that omit the Alt-Svc parameter "signature-
algorithm" imply that either:
o the session does not use the content authenticity mechanism, or o the session does not use the content authenticity mechanism, or
o the algorithm set is unrestricted i.e. a sender may vary the o the algorithm set is unrestricted i.e. a sender may vary the
algorithm as it so chooses. This may lead to undesirable results algorithm as it so chooses. This may lead to undesirable results
if receivers do not support a chosen algorithm. if receivers do not support a chosen algorithm.
Advertising the algorithm set for a session gives receivers the Advertising the algorithm set for a session gives receivers the
opportunity to selectively join sessions where the algorithms are opportunity to selectively join sessions where the algorithms are
known to be supported. This may help to mitigate latency issues in known to be supported. This may help to mitigate latency issues in
skipping to change at page 16, line 20 skipping to change at page 17, line 26
A multicast sender participating in a session MUST NOT use algorithms A multicast sender participating in a session MUST NOT use algorithms
outside the signalled signature algorithm set. A receiver MAY leave outside the signalled signature algorithm set. A receiver MAY leave
any session where an algorithm outside the signature algorithm set is any session where an algorithm outside the signature algorithm set is
used. used.
4. QUIC Profile 4. QUIC Profile
*Authors' Note:* The QUIC transport document is subject to change. *Authors' Note:* The QUIC transport document is subject to change.
This section is based on our best understanding of draft-ietf- This section is based on our best understanding of draft-ietf-
quic-transport-04. The authors will track developments and will quic-transport-09. The authors will track developments and will
update this section accordingly. update this section accordingly.
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 9 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. Version Negotiation 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 format. This header format omits a Version with the short header form. This header form omits the Version
field. field.
*Authors' Note:* The authors welcome suggestions for conveying the *Authors' Note:* The authors welcome suggestions for conveying the
QUIC version in every multicast QUIC packet. QUIC version in every multicast QUIC packet.
4.3. Connection Identifier 4.3. Connection Identifier
The Connection ID field MUST be present in every QUIC packet, and the The Connection ID field MUST be present in every QUIC packet, and the
corresponding flag in the packet header MUST be set to indicate that corresponding flag in the packet header MUST be set to indicate that
the Connection ID field is present. the Connection ID field is present.
4.4. Stream Identifier 4.4. Stream Identifier
The maximum Stream ID of a multicast QUIC session is 2^62, as
explained in Section 3.6.
Senders MUST NOT send any QUIC frames on QUIC stream 0. Receivers Senders MUST NOT send any QUIC frames on QUIC stream 0. Receivers
MUST ignore QUIC frames received on stream 0. MUST ignore QUIC frames received on stream 0.
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 "MAX_DATA" or "MAX_STREAM_DATA" and endpoints manage this by sending QUIC "MAX_DATA" or
QUIC frames as required. When a sender is blocked from sending flow- "MAX_STREAM_DATA" frames as required. When a sender is blocked from
controlled frames, it sends an informational "BLOCKED" or sending flow-controlled frames, it sends an informational QUIC
"STREAM_BLOCKED" QUIC 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 "MAX_DATA", information is not supported by this profile. The QUIC "MAX_DATA",
"MAX_STREAM_DATA", "BLOCKED" and "STREAM_BLOCKED" QUIC 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.10.
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 "STREAM" QUIC frame, or QUIC Stream ID by setting the "FIN" bit of a QUIC "STREAM" frame, or
by sending a "RST_STREAM" QUIC frame (as specified in by sending a QUIC "RST_STREAM" frame (as specified in
[QUIC-TRANSPORT] and [QUIC-HTTP]). [QUIC-TRANSPORT] and [QUIC-HTTP]).
Receiving participants MUST NOT make any attempt to send "RST_STREAM" Receiving participants MUST NOT make any attempt to send QUIC
to the multicast group. "RST_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. The "GOAWAY" and "CONNECTION_CLOSE" not supported by this profile.
QUIC frames, and the Public Reset packet are prohibited.
Participants MUST NOT send these and reception MUST be handled as The QUIC "APPLICATION_CLOSE" and "CONNECTION_CLOSE" frames, and the
described in Section 4.10. Public Reset packet are prohibited. Participants MUST NOT send these
and reception MUST be handled as described in Section 4.10.
The HTTP/QUIC "GOAWAY" frame is prohibited. Participants MUST NOT
send this and reception MUST be handled as described in Section 5.7.
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. 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 data to send sender. There may be periods where the sender has no application
for a period longer than the session idle timeout. This profile data to send for a period longer than the session idle timeout. This
repurposes the "PING" QUIC frame to act as a unidirectional keep- profile repurposes the QUIC "PING" frame to act as a unidirectional
alive message that may be sent in order to inform receivers that the keep-alive message that may be sent in order to inform receivers that
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
"PING" frames.
Senders MAY send a "PING" frame at any time in order to inform Senders MAY send a QUIC "PING" frame with an empty Data field at any
receivers that the session traffic flow has not fallen idle. This time in order to inform receivers that the session traffic flow has
frame MUST NOT be acknowledged. (Indeed "ACK" frames are banned by not fallen idle. This frame MUST NOT be acknowledged. Indeed, QUIC
Section 4.9.) "ACK" frames are prohibited by this profile (Section 4.9).
Receiving participants MUST NOT make any attempt to send "PING" 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"
frames. frames.
4.9. Loss Detection and Recovery 4.9. 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 "ACK" QUIC 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.10.
Section 7 specifies alternative strategies for loss recovery. Section 7 specifies alternative strategies for loss recovery.
4.10. Prohibited QUIC Frames and Packets 4.10. 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 0-RTT Protected, 1-RTT Protected (key phase 0), 1-RTT Protected (key
phase 1), Client Cleartext, Client Initial, Public Reset, Server phase 1), Client Cleartext, Client Initial, Public Reset, Server
Cleartext, Server Initial, Version Negotiation. 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", "BLOCKED", "CONNECTION_CLOSE", "GOAWAY", "MAX_DATA", "ACK", "APPLICATION_CLOSE", "BLOCKED", "CONNECTION_CLOSE",
"MAX_STREAM_DATA", "STREAM_BLOCKED". "MAX_DATA", "MAX_STREAM_ID", "MAX_STREAM_DATA", "PING" (with Data),
"PONG", "STREAM_BLOCKED", "STREAM_ID_BLOCKED".
The following QUIC frames MUST NOT be transmitted by receivers: The following QUIC frames MUST NOT be transmitted by receivers:
"RST_STREAM". "RST_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/QUIC Profile
*Authors' Note:* The HTTP/QUIC mapping document is subject to *Authors' Note:* The HTTP/QUIC mapping document is subject to
change. This section is based on our best understanding of draft- change. This section is based on our best understanding of draft-
ietf-quic-http-04. The authors will track developments and will ietf-quic-http-09. The authors will track developments and will
update this section accordingly. update 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 "STREAM" participating in a session pushes resources as a series of QUIC
QUIC frames carrying HTTP/2 "PUSH_PROMISE", "HEADERS" and body data. "STREAM" frames carrying HTTP/QUIC "PUSH_PROMISE", "HEADERS" and
Examples of this are provided in Appendix B.2. Senders MUST comply "DATA" frames. Examples of this are provided in Appendix B.2.
with the requirements of the session parameters, as described earlier Senders MUST comply with the requirements of the session parameters,
in Section 3. as described earlier in Section 3.
The profile of HTTP/QUIC specified in this section places additional The profile of HTTP/QUIC 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 "SETTINGS" HTTP/2 frame is prohibited by this profile. The HTTP/QUIC "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, enabled for HTTP/QUIC connections. A Server push is, by default, disabled for HTTP/QUIC connections. A
conventional HTTP/QUIC client may disable server push via a conventional HTTP/QUIC client enables and manages server push by
"SETTINGS" HTTP/2 frame but the use of that frame is prohibited by controlling the maximum Push ID ([QUIC-HTTP], Section 5.2.6),
this profile (Section 5.1). This profile mandates the use of server achieved by sending the HTTP/QUIC "MAX_PUSH_ID" frame.
push, and specifies no means to disable it.
This profile mandates the use of server push, and specifies no means
to disable it. The maximum Push ID for multicast QUIC sessions
(initial and always) is 2^62.
Server push concurrency in multicast QUIC is described in
Section 3.6. There is no role for the HTTP/QUIC "MAX_PUSH_ID" frame
and it is prohibited. Participants MUST NOT send this frame type.
Reception of this frame type MUST be handled as described in
Section 5.7.
The HTTP/QUIC "CANCEL_PUSH" frame MAY be used by sending participants
to abort sending a response for the identified server push. Usage of
this frame should follow the guidance for servers in [QUIC-HTTP].
Receiving participants MUST NOT make any attempt to send QUIC
"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 HTTP/2 stream ID that would normally be used for the first client the first client-initiated, bidirectional QUIC stream. HTTP/QUIC
request. "PUSH_PROMISE" frames MUST reference this reserved 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. accordingly. The possibility of sending HTTP/QUIC "PUSH_PROMISE"
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 HPACK
[RFC7541], which describes two methods for the compression of HTTP [RFC7541], 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 *Authors' Note:* In the context of QUIC, changes to HPACK may
allow for better leverage of the transport. QPACK [QPACK] and allow for better leverage of the transport. QPACK
[QCRAM] are active proposals in this space. This section will ([I-D.bishop-quic-http-and-qpack]), QCRAM
track developments and will be updated accordingly. ([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 "PRIORITY" HTTP/2 frame is prohibited by this profile. The HTTP/QUIC "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/2 Extension frames 5.6. HTTP/QUIC Extension frames
HTTP/2 extension frames (e.g. "ALTSVC") are prohibited by this HTTP/QUIC 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/2 Frames 5.7. Prohibited HTTP/QUIC Frames
The following HTTP/2 frames MUST NOT be transmitted by participants: The following HTTP/QUIC frames MUST NOT be transmitted by
"PRIORITY", "SETTINGS". participants: "GOAWAY", "MAX_PUSH_ID", "PRIORITY", "SETTINGS".
In addition, all HTTP/2 extension frame types MUST NOT be transmitted In addition, all HTTP/QUIC extension frame types MUST NOT be
by participants. transmitted by participants.
Reception of a prohibited HTTP/2 frame is a protocol error. The following HTTP/QUIC frames MUST NOT be transmitted by receivers:
Receivers MUST ignore prohibited HTTP/2 frames. "CANCEL_PUSH".
Reception of a prohibited HTTP/QUIC frame is a protocol error.
Receivers MUST ignore prohibited HTTP/QUIC 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 21, line 38 skipping to change at page 23, line 27
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 "HEADERS" frame of any A sender MAY include this header in the HTTP/QUIC "HEADERS" frame of
representation it transmits and a receiver MAY use this header to any 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.
In cases where the complete representation is not available at the
start of multicast transmission, the "Digest" header MAY be conveyed
as a trailing header field after the body data of the representation,
in accordance with Section 8.1 of [RFC7540].
Any of the algorithms specified in the IANA registry of digest Any of the algorithms specified in the IANA registry of digest
algorithms (http://www.iana.org/assignments/http-dig-alg/http-dig- algorithms (http://www.iana.org/assignments/http-dig-alg/http-dig-
alg.xhtml#http-dig-alg-1) MAY be used in conjunction with the alg.xhtml#http-dig-alg-1) MAY be used in conjunction with the
"Digest" header. There is no requirement for participants to support "Digest" header. There is no requirement for participants to support
the full set of algorithms. the full set of algorithms.
6.2. Content Authenticity 6.2. Content Authenticity
In some applications, it is important for a receiver to reassure In some applications, it is important for a receiver to reassure
itself that an HTTP representation has been received from an itself that an HTTP representation has been received from an
skipping to change at page 22, line 39 skipping to change at page 24, line 23
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 "PUSH_PROMISE" frame (protecting the request metadata) and in in the HTTP/QUIC "PUSH_PROMISE" frame (protecting the request
the final (or only) "HEADERS" frame relating to a particular resource metadata) and in the final (or only) HTTP/QUIC "HEADERS" frame
(protecting the response metadata). In order to provide an relating to a particular resource (protecting the response metadata).
additional level of protection, however, it is RECOMMENDED that the In order to provide an additional level of protection, however, it is
signature be computed over the combined request metadata (from the RECOMMENDED that the signature be computed over the combined request
"PUSH_PROMISE" frame) and the corresponding response metadata (from metadata (from the "PUSH_PROMISE" frame) and the corresponding
the "HEADERS" frames) of the same resource. This binds the request response metadata (from the HTTP/QUIC "HEADERS" frames) of the same
metadata and response metadata together, providing the receiver with resource. This binds the request metadata and response metadata
additional reassurance of authenticity. In this latter case, the together, providing the receiver with additional reassurance of
combined digital signature SHALL be conveyed in the final (or only) authenticity. In this latter case, the combined digital signature
"HEADERS" frame. SHALL be conveyed in the final (or only) HTTP/QUIC "HEADERS" frame.
In cases where not all metadata is known at the start of
transmission, the "Signature" header MAY be conveyed as a trailing
header field after the body data of the representation, in accordance
with Section 8.1 of [RFC7540].
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 24, line 4 skipping to change at page 25, line 31
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
chartered to specify one (or more) new FEC schemes in the future. chartered to specify one (or more) new FEC schemes in the future.
This section will track developments in this area, and will be This section will track developments in this area, and will be
updated accordingly. updated accordingly.
A sender MAY make use of a suitable Forward Error Correction scheme A sender MAY make use of a suitable Forward Error Correction scheme
to allow a receiver to reconstruct lost packets from those that have to allow a receiver to reconstruct lost packets from those that have
been successfully received. been successfully received.
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 "HEADERS" HTTP/2 frame. length" response header carried in the HTTP/QUIC "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 "STREAM" QUIC 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
received as part of a previous unicast HTTP response according to the received as part of a previous unicast HTTP response according to the
rules in [RFC7838]. rules in [RFC7838].
skipping to change at page 24, line 48 skipping to change at page 26, line 29
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 "PUSH_PROMISE" HTTP/2 frame. the HTTP/QUIC "PUSH_PROMISE" frame.
o The corresponding "HEADERS" HTTP/2 frame SHALL indicate HTTP o The corresponding HTTP/QUIC "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. Either or both indicated in a "content-length" header field.
of these headers fields MAY be transmitted in a trailing
"HEADERS" frame if their values are not known at the start of
transmission.
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)
[RFC7301] identifier "hqm". The IANA registration of this protocol [RFC7301] identifier "hqm". The IANA registration of this protocol
identifier can be found in Section 12.1. This reserves the ALPN identifier can be found in Section 12.1. This reserves the ALPN
identifier space but describes a protocol that does not use TLS. The identifier space but describes a protocol that does not use TLS. The
usage of the "hqm" identifier for discoverability is described in usage of the "hqm" identifier for discoverability is described in
Section 10. Section 10.
skipping to change at page 32, line 27 skipping to change at page 33, line 43
SHOULD have reasonable assurance that the alternative service is SHOULD have reasonable assurance that the alternative service is
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 "ACK" frame is [QUIC-TRANSPORT] is out of scope because use of the QUIC "ACK" frame
prohibited (Section 4.9) by the present document. is prohibited (Section 4.9) 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 37, line 11 skipping to change at page 38, line 29
Parameter name: signature-algorithm Parameter name: signature-algorithm
Specification: This document, Section 10.2.10 Specification: This document, Section 10.2.10
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-07 (work in progress), July 2017. cavage-http-signatures-09 (work in progress), November
2017.
[QUIC-HTTP] [QUIC-HTTP]
Bishop, M., Ed., "Hypertext Transfer Protocol (HTTP) over Bishop, M., Ed., "Hypertext Transfer Protocol (HTTP) over
QUIC", draft-ietf-quic-http-04 (work in progress). QUIC", draft-ietf-quic-http-09 (work in progress).
[QUIC-RECOVERY]
Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection
and Congestion Control", draft-ietf-quic-recovery-04 (work
in progress).
[QUIC-TLS]
Thomson, M., Ed. and S. Turner, Ed, Ed., "Using Transport
Layer Security (TLS) to Secure QUIC", draft-ietf-quic-
tls-04 (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-04 (work in progress). transport-09 (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-
<http://www.rfc-editor.org/info/rfc2119>. editor.org/info/rfc2119>.
[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,
<http://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,
<http://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,
DOI 10.17487/RFC5234, January 2008, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc5234>. editor.org/info/rfc5234>.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Message Syntax and Routing", Protocol (HTTP/1.1): Message Syntax and Routing",
RFC 7230, DOI 10.17487/RFC7230, June 2014, RFC 7230, DOI 10.17487/RFC7230, June 2014,
<http://www.rfc-editor.org/info/rfc7230>. <https://www.rfc-editor.org/info/rfc7230>.
[RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., [RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
"Hypertext Transfer Protocol (HTTP/1.1): Range Requests", "Hypertext Transfer Protocol (HTTP/1.1): Range Requests",
RFC 7233, DOI 10.17487/RFC7233, June 2014, RFC 7233, DOI 10.17487/RFC7233, June 2014,
<http://www.rfc-editor.org/info/rfc7233>. <https://www.rfc-editor.org/info/rfc7233>.
[RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
RFC 7234, DOI 10.17487/RFC7234, June 2014, RFC 7234, DOI 10.17487/RFC7234, June 2014,
<http://www.rfc-editor.org/info/rfc7234>. <https://www.rfc-editor.org/info/rfc7234>.
[RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan,
"Transport Layer Security (TLS) Application-Layer Protocol "Transport Layer Security (TLS) Application-Layer Protocol
Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,
July 2014, <http://www.rfc-editor.org/info/rfc7301>. July 2014, <https://www.rfc-editor.org/info/rfc7301>.
[RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF", [RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF",
RFC 7405, DOI 10.17487/RFC7405, December 2014, RFC 7405, DOI 10.17487/RFC7405, December 2014,
<http://www.rfc-editor.org/info/rfc7405>. <https://www.rfc-editor.org/info/rfc7405>.
[RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
DOI 10.17487/RFC7540, May 2015,
<http://www.rfc-editor.org/info/rfc7540>.
[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, <http://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
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
13.2. Informative References 13.2. Informative References
[QCRAM] Krasic, C., Ed., "Header Compression for HTTP over QUIC", [I-D.bishop-quic-http-and-qpack]
draft-krasic-quic-qcram-02 (work in progress). Bishop, M., "Header Compression for HTTP/QUIC", draft-
bishop-quic-http-and-qpack-07 (work in progress), December
2017.
[QPACK] Bishop, M., Ed., "Header Compression for HTTP/QUIC", [I-D.krasic-quic-qcram]
draft-bishop-quic-http-and-qpack-02 (work in progress). Krasic, C., "Header Compression for HTTP over QUIC",
draft-krasic-quic-qcram-04 (work in progress), January
2018.
[QUICCrypto] [I-D.tikhonov-quic-qmin]
Langley, A. and W. Chang, "QUIC Crypto", May 2016, Tikhonov, D., "QMIN: Header Compression for QUIC", draft-
<http://goo.gl/OuVSxa>. tikhonov-quic-qmin-00 (work in progress), November 2017.
[QUIC-RECOVERY]
Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection
and Congestion Control", draft-ietf-quic-recovery-09 (work
in progress).
[QUIC-TLS]
Thomson, M., Ed. and S. Turner, Ed, Ed., "Using Transport
Layer Security (TLS) to Secure QUIC", draft-ietf-quic-
tls-09 (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,
<http://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-
<http://www.rfc-editor.org/info/rfc1191>. editor.org/info/rfc1191>.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
December 1998, <http://www.rfc-editor.org/info/rfc2460>. December 1998, <https://www.rfc-editor.org/info/rfc2460>.
[RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session
Announcement Protocol", RFC 2974, DOI 10.17487/RFC2974, Announcement Protocol", RFC 2974, DOI 10.17487/RFC2974,
October 2000, <http://www.rfc-editor.org/info/rfc2974>. October 2000, <https://www.rfc-editor.org/info/rfc2974>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
DOI 10.17487/RFC3261, June 2002, DOI 10.17487/RFC3261, June 2002, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc3261>. editor.org/info/rfc3261>.
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
Thyagarajan, "Internet Group Management Protocol, Version Thyagarajan, "Internet Group Management Protocol, Version
3", RFC 3376, DOI 10.17487/RFC3376, October 2002, 3", RFC 3376, DOI 10.17487/RFC3376, October 2002,
<http://www.rfc-editor.org/info/rfc3376>. <https://www.rfc-editor.org/info/rfc3376>.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
July 2003, <http://www.rfc-editor.org/info/rfc3550>. July 2003, <https://www.rfc-editor.org/info/rfc3550>.
[RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener
Discovery Version 2 (MLDv2) for IPv6", RFC 3810, Discovery Version 2 (MLDv2) for IPv6", RFC 3810,
DOI 10.17487/RFC3810, June 2004, DOI 10.17487/RFC3810, June 2004, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc3810>. editor.org/info/rfc3810>.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, DOI 10.17487/RFC4566, Description Protocol", RFC 4566, DOI 10.17487/RFC4566,
July 2006, <http://www.rfc-editor.org/info/rfc4566>. July 2006, <https://www.rfc-editor.org/info/rfc4566>.
[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,
<http://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-
<http://www.rfc-editor.org/info/rfc5737>. editor.org/info/rfc5737>.
[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,
<http://www.rfc-editor.org/info/rfc6676>. <https://www.rfc-editor.org/info/rfc6676>.
[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, <http://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-
<http://www.rfc-editor.org/info/rfc7450>. editor.org/info/rfc7450>.
[RFC7541] Peon, R. and H. Ruellan, "HPACK: Header Compression for [RFC7541] Peon, R. and H. Ruellan, "HPACK: Header Compression for
HTTP/2", RFC 7541, DOI 10.17487/RFC7541, May 2015, HTTP/2", RFC 7541, DOI 10.17487/RFC7541, May 2015,
<http://www.rfc-editor.org/info/rfc7541>. <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, <http://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. Sam Hurst, 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.
skipping to change at page 42, line 17 skipping to change at page 43, line 33
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 "PUSH_PROMISE" or "HEADERS" HTTP/2 frames describe Examples that show HTTP/QUIC "PUSH_PROMISE" or "HEADERS" frames
the contents of enclosed header block fragments. describe 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
"PUSH_PROMISE" HTTP/2 frame: HTTP/QUIC "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
"HEADERS" HTTP/2 frame; HTTP/QUIC "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
QUIC "STREAM" frame containing 100 bytes of response body data: HTTP/QUIC "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 intention to transfer all 100 bytes of the representation, sender's original intention to transfer all 100 bytes of the
but the "Content-Range" trailing response header indicates that only representation. The "Content-Range" response header indicates that
the first 50 bytes were actually transferred. only the first 50 bytes were actually sent.
"PUSH_PROMISE" HTTP/2 frame: HTTP/QUIC "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-*
Leading "HEADERS" HTTP/2 frame: HTTP/QUIC "HEADERS" frame:
:status: 206 :status: 206
content-length: 100 content-length: 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
"STREAM" QUIC frame containing 50 bytes of response body data: HTTP/QUIC "DATA" frame containing 50 bytes of response body data:
... ...
Trailing "HEADERS" HTTP/2 frame indicating the range of bytes sent:
content-range: bytes 0-49/100
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.
"PUSH_PROMISE" HTTP/2 frame: HTTP/QUIC "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
"HEADERS" HTTP/2 frame including the "Digest" header: HTTP/QUIC "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=
"STREAM" QUIC frame containing 100 bytes of response body data: HTTP/QUIC "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.
but the "Content-Range" trailing response header indicates that only The "Content-Range" response header indicates that only the first 50
the first 50 bytes were actually transferred. Content integrity is bytes were actually sent. Content integrity is assured by the
assured by the inclusion of the "Digest" response header, as inclusion of the "Digest" response header, as described in
described in Section 6.1. Section 6.1.
"PUSH_PROMISE" HTTP/2 frame: HTTP/QUIC "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-*
Leading "HEADERS" HTTP/2 frame including the "Digest" header: HTTP/QUIC "HEADERS" frame including the "Digest" header:
:status: 206 :status: 206
content-length: 100 content-length: 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=
"STREAM" QUIC frame containing 50 bytes of response body data: HTTP/QUIC "DATA" frame containing 50 bytes of response body data:
... ...
Trailing "HEADERS" HTTP/2 frame indicating the range of bytes sent:
content-range: bytes 0-49/100
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.
"PUSH_PROMISE" HTTP/2 frame including a "Signature" header protecting HTTP/QUIC "PUSH_PROMISE" frame including a "Signature" header
the ":method" and ":path" (the request target), as well as the protecting the ":method" and ":path" (the request target), as well as
":scheme" and ":authority" of the pseudo-request: the ":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"
"HEADERS" HTTP/2 frame including a "Signature" header protecting the HTTP/QUIC "HEADERS" frame including a "Signature" header protecting
":method", ":path", ":scheme" and ":authority" of the pseudo-request the ":method", ":path", ":scheme" and ":authority" of the pseudo-
above, plus the "Date" and "Digest" of the response: request 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"
"STREAM" QUIC frame containing response body data: HTTP/QUIC "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.
"PUSH_PROMISE" HTTP/2 frame: HTTP/QUIC "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"
Leading "HEADERS" HTTP/2 frame: HTTP/QUIC "HEADERS" frame protecting the ":method", ":path",
":scheme" and ":authority" of the pseudo-request above, plus the
"Date", "Digest" and "Content-Range" of the response:
:status: 206 :status: 206
content-length: 100 content-length: 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=
"STREAM" QUIC frame containing response body data:
...
Trailing "HEADERS" HTTP/2 frame protecting the ":method", ":path",
":scheme" and ":authority" of the pseudo-request above, plus the
"Date", "Digest" and "Content-Range" of the response:
content-range: bytes 0-49/100
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"
Appendix C. Changelog HTTP/QUIC "DATA" frame containing response body data:
...
Appendix C. Summary of differences from unicast QUIC and HTTP/QUIC
+----------------+-------------------------+------------------------+
| Protocol | Unicast QUIC | Multicast HTTP/QUIC |
| feature | | profile |
+----------------+-------------------------+------------------------+
| Stream ID 0 | Combined cryptography | Reserved Stream ID not |
| | and transport handshake | used. |
| | stream conveying TLS | |
| | handshake messages in | |
| | QUIC "STREAM" frames. | |
| | | |
| TLS cipher | Client's preferred | Cipher suite |
| suite | cipher suite included | optionally advertised |
| | in Client Hello | out of band via Alt- |
| | message. | Svc "cipher-suite" |
| | | parameter. Default |
| | | cipher suite is |
| | | "0x00,0x00 (NULL_WITH_ |
| | | NULL_NULL)". |
| | | |
| TLS session | Session key included in | Session key optionally |
| key | Server Hello message. | advertised out of band |
| | | via Alt-Svc "key" |
| | | parameter. |
| | | |
| TLS | Initialization vector | Initialization vector |
| initialization | included in Server | optionally advertised |
| vector | Hello message. | out of band via Alt- |
| | | Svc "iv" parameter. |
| | | |
| Required QUIC | "idle_timeout" | Advertised out of band |
| TransportParam | | via Alt-Svc "session- |
| eter for idle | | idle-timeout" |
| timeout | | parameter. |
| | | |
| Required QUIC | "initial_max_data" | Not Used. Peak flow |
| TransportParam | | rate of a session |
| 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
+-------------+----------------+--------------------------------------+
| Protocol | Unicast QUIC | Multicast HTTP/QUIC profile |
| feature | | |
+-------------+----------------+--------------------------------------+
| Maximum | Determined by | Determined by path MTU discovery or |
| packet size | path MTU | other heuristic. |
| | discovery or | |
| | other | |
| | heuristic. | |
| | | |
| Version | Protocol | Not permitted. (No negotiation |
| negotiation | version | possible in multicast context.) |
| packet | negotiation | "VERSION" flag in QUIC packet header |
| | between | must never be set. Protocol version |
| | initiating | advertised out of band via Alt-Svc |
| | client and | "quic" parameter. |
| | server. | |
| | | |
| Public | Connection | Not permitted. (Potential denial-of- |
| reset | reset. | service attack vector.) |
| packet | | "PUBLIC_RESET" flag in QUIC packet |
| | | header must never be set. |
| | | |
| Regular | Used to convey | Used to convey QUIC frames (see |
| packet | QUIC frames | below). Only the short header form |
| | (see below). | is permitted. |
| | | |
| Connection | Randomly | Redefined to be a multicast Session |
| ID field | assigned by | ID. Value assigned by the multicast |
| | initiating | sender. Connection ID field is |
| | client and/or | present in all multicast QUIC |
| | server. | packets. "CONNECTION_ID" flag in |
| | Different | QUIC packet header must always be |
| | Connection IDs | set. The same Session ID may span |
| | may not be | several multicast groups. Different |
| | multiplexed on | Session IDs may be multiplexed on |
| | the same | the same 5-tuple source-specific |
| | 5-tuple | multicast group and port. |
| | network | |
| | association? | |
+-------------+----------------+--------------------------------------+
Table 2: QUIC Packet Layer
+---------------------+-------------------------+---------------------+
| Protocol feature | Unicast QUIC | Multicast HTTP/QUIC |
| | | profile |
+---------------------+-------------------------+---------------------+
| "ACK" frame | Used by a receiver to | Prohibited. |
| | acknowledge receipt of | |
| | data from its peer. | |
| | | |
| "APPLICATION_CLOSE" | Notification (by either | Prohibited. |
| frame | endpoint) of immediate | |
| | connection closure. | |
| | | |
| "BLOCKED" frame | Notification to | Prohibited. |
| | receiver that sender's | |
| | transmission is blocked | |
| | pending an update to | |
| | its flow control window | |
| | by peer. | |
| | | |
| "CONNECTION_CLOSE" | Notification (by either | Prohibited. Use |
| frame | endpoint) of immediate | HTTP explicit |
| | connection closure. | session tear-down |
| | | instead (see |
| | | HTTP/QUIC mapping |
| | | below). |
| | | |
| "MAX_DATA" frame | Flow control update | Prohibited. |
| | notification. | |
| | | |
| "MAX_STREAM_DATA" | Flow control update | Prohibited. |
| frame | notification. | |
| | | |
| "MAX_STREAM_ID" | Used by an endpoint to | Prohibited. |
| frame | inform a peer of the | |
| | maximum stream ID that | |
| | it is permitted to | |
| | open. | |
| | | |
| "PADDING" frame | Used to pad out a QUIC | Permitted, but |
| | packet with zero bytes. | wasteful of network |
| | (The first packet sent | capacity. |
| | 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 to | Used by the |
| | verify that its peer is | multicast sender as |
| | still alive. | a session keep- |
| | Acknowledged using | alive notification. |
| | "PING" or "PONG" | "PING" with data is |
| | | prohibited. Never |
| | | acknowledged. |
| | | |
| "PONG" frame | Sent in response to a | Prohibited. |
| | PING frame that | |
| | 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
+----------------+------------------+-------------------------------+
| Protocol | Unicast | Multicast HTTP/QUIC profile |
| feature | HTTP/QUIC | |
+----------------+------------------+-------------------------------+
| "ALTSVC" frame | Signalling | Prohibited. |
| | alternative | |
| | service for | |
| | HTTP/QUIC | |
| | session. | |
| | | |
| "CANCEL_PUSH" | Used to request | Permitted only for senders. |
| frame | cancellation of | |
| | server push | |
| | prior to the | |
| | push stream | |
| | being created. | |
| | | |
| "DATA" frame | Carriage of HTTP | Carriage of HTTP response |
| | request/response | message body. |
| | message body. | |
| | | |
| "GOAWAY" frame | Early | Prohibited. Use HTTP explicit |
| | notification (by | session tear-down instead. |
| | either endpoint) | |
| | of future | |
| | connection | |
| | closure, | |
| | allowing for | |
| | orderly | |
| | completion of | |
| | open streams. | |
| | | |
| "HEADERS" | Carriage of HTTP | Carriage of HTTP response |
| frame | request/response | message metadata. Trailing |
| | message | HEADERS frame is permitted. |
| | metadata. | |
| | Trailing HEADERS | |
| | frame is | |
| | permitted. | |
| | | |
| "MAX_PUSH_ID" | Used by a | Prohibited. |
| frame | receiver to | |
| | control the | |
| | number of server | |
| | pushes that a | |
| | sender can | |
| | 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
+-------------+----------------------------------+------------------+
| Protocol | Unicast HTTP/QUIC | Multicast |
| feature | | HTTP/QUIC |
| | | profile |
+-------------+----------------------------------+------------------+
| Huffman | Header blocks may use Huffman | Header blocks |
| string | codes to compress literal string | may use Huffman |
| compression | values. | codes to |
| | | compress literal |
| | | string values. |
| | | |
| Static | Header blocks may refer to | Header blocks |
| table | indexed entries in the static | may refer to |
| | table. | indexed entries |
| | | in the static |
| | | table. |
| | | |
| Dynamic | Header blocks may insert entries | Prohibited, size |
| table | into the dynamic table and | is currently |
| | subsequent header blocks may | locked to 0. |
| | refer to their indexes. Unused | |
| | as size is currently locked to | |
| | 0. | |
+-------------+----------------------------------+------------------+
Table 5: HTTP Metadata Compression Layer
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.
C.1. Since draft-pardue-quic-http-mcast-00 D.1. Since draft-pardue-quic-http-mcast-01
o Explicit guidance on maximum stream ID value permitted.
o Updated guidance on PING (and PONG) frame.
o Added a comparison table to appendix.
o Remove invalid use of trailing headers.
o Use the new HTTP/QUIC DATA frame.
o Prohibit APPLICATION CLOSE frame, and move GOAWAY frame to HTTP/
QUIC section.
o Redefine server push to reflect core document changes.
o Remove default idle time out value.
o Clarify session parameter requirements (session-idle-timeout
became mandatory).
o Update frame notation convention.
D.2. 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.
 End of changes. 139 change blocks. 
387 lines changed or deleted 784 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/