< draft-pardue-quic-http-mcast-00.txt		draft-pardue-quic-http-mcast-01.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: August 14, 2017 February 10, 2017		Expires: February 12, 2018 August 11, 2017
	Hypertext Transfer Protocol (HTTP) over multicast QUIC		Hypertext Transfer Protocol (HTTP) over multicast QUIC
	draft-pardue-quic-http-mcast-00		draft-pardue-quic-http-mcast-01
	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 August 14, 2017.		This Internet-Draft will expire on February 12, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 IETF Trust and the persons identified as the		Copyright (c) 2017 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
	skipping to change at page 2, line 24 ¶		skipping to change at page 2, line 24 ¶
	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 . . . . . . . . . . . . . . . . . 9
	2.4. Session Security . . . . . . . . . . . . . . . . . . . . 10		2.4. Session Security . . . . . . . . . . . . . . . . . . . . 10
	3. Session Advertisement . . . . . . . . . . . . . . . . . . . . 10		3. Session Advertisement . . . . . . . . . . . . . . . . . . . . 10
	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.3. Session Identification . . . . . . . . . . . . . . . . . 12
	3.4. Session Idle Timeout . . . . . . . . . . . . . . . . . . 12		3.4. Session Idle Timeout . . . . . . . . . . . . . . . . . . 13
	3.5. Session Peak Flow Rate . . . . . . . . . . . . . . . . . 13		3.5. Session Peak Flow Rate . . . . . . . . . . . . . . . . . 13
	3.6. Resource Concurrency . . . . . . . . . . . . . . . . . . 13		3.6. Resource Concurrency . . . . . . . . . . . . . . . . . . 13
	3.7. Connection Options . . . . . . . . . . . . . . . . . . . 14		3.7. Additional TransportParameter Considerations . . . . . . 14
	4. QUIC Profile . . . . . . . . . . . . . . . . . . . . . . . . 14		3.8. Digest Algorithm . . . . . . . . . . . . . . . . . . . . 14
	4.1. Packet Size . . . . . . . . . . . . . . . . . . . . . . . 14		3.9. Signature Algorithm . . . . . . . . . . . . . . . . . . . 15
	4.2. Version Negotiation . . . . . . . . . . . . . . . . . . . 14		4. QUIC Profile . . . . . . . . . . . . . . . . . . . . . . . . 16
	4.3. Connection Identifier . . . . . . . . . . . . . . . . . . 14		4.1. Packet Size . . . . . . . . . . . . . . . . . . . . . . . 16
	4.4. Stream Identifier . . . . . . . . . . . . . . . . . . . . 14		4.2. Version Negotiation . . . . . . . . . . . . . . . . . . . 16
	4.5. Flow Control . . . . . . . . . . . . . . . . . . . . . . 15		4.3. Connection Identifier . . . . . . . . . . . . . . . . . . 17
	4.6. Stream Termination . . . . . . . . . . . . . . . . . . . 15		4.4. Stream Identifier . . . . . . . . . . . . . . . . . . . . 17
	4.7. Session Shutdown . . . . . . . . . . . . . . . . . . . . 15		4.5. Flow Control . . . . . . . . . . . . . . . . . . . . . . 17
	4.8. Session Keep-alive . . . . . . . . . . . . . . . . . . . 15		4.6. Stream Termination . . . . . . . . . . . . . . . . . . . 17
	4.9. Loss Detection and Recovery . . . . . . . . . . . . . . . 16		4.7. Session Shutdown . . . . . . . . . . . . . . . . . . . . 17
	4.10. Prohibited QUIC Frames and Packets . . . . . . . . . . . 16		4.8. Session Keep-alive . . . . . . . . . . . . . . . . . . . 18
	5. HTTP/QUIC Profile . . . . . . . . . . . . . . . . . . . . . . 16		4.9. Loss Detection and Recovery . . . . . . . . . . . . . . . 18
	5.1. HTTP Connection Settings . . . . . . . . . . . . . . . . 17		4.10. Prohibited QUIC Frames and Packets . . . . . . . . . . . 18
	5.2. Server Push . . . . . . . . . . . . . . . . . . . . . . . 17		5. HTTP/QUIC Profile . . . . . . . . . . . . . . . . . . . . . . 19
	5.3. Metadata Compression . . . . . . . . . . . . . . . . . . 17		5.1. HTTP Connection Settings . . . . . . . . . . . . . . . . 19
	5.4. Prioritisation . . . . . . . . . . . . . . . . . . . . . 18		5.2. Server Push . . . . . . . . . . . . . . . . . . . . . . . 19
	5.5. Session Tear-down . . . . . . . . . . . . . . . . . . . . 18		5.3. Metadata Compression . . . . . . . . . . . . . . . . . . 20
	5.6. HTTP/2 Extension frames . . . . . . . . . . . . . . . . . 18		5.4. Prioritisation . . . . . . . . . . . . . . . . . . . . . 20
	5.7. Prohibited HTTP/2 Frames . . . . . . . . . . . . . . . . 18		5.5. Session Tear-down . . . . . . . . . . . . . . . . . . . . 20
	6. Application-Layer Security . . . . . . . . . . . . . . . . . 18		5.6. HTTP/2 Extension frames . . . . . . . . . . . . . . . . . 20
	6.1. Content Integrity . . . . . . . . . . . . . . . . . . . . 18		5.7. Prohibited HTTP/2 Frames . . . . . . . . . . . . . . . . 21
	6.2. Content Authenticity . . . . . . . . . . . . . . . . . . 19		6. Application-Layer Security . . . . . . . . . . . . . . . . . 21
	6.3. Content Confidentiality . . . . . . . . . . . . . . . . . 21		6.1. Content Integrity . . . . . . . . . . . . . . . . . . . . 21
	7. Loss Recovery . . . . . . . . . . . . . . . . . . . . . . . . 21		6.2. Content Authenticity . . . . . . . . . . . . . . . . . . 22
	7.1. Forward Error Correction . . . . . . . . . . . . . . . . 21		6.3. Content Confidentiality . . . . . . . . . . . . . . . . . 23
	7.2. Unicast Repair . . . . . . . . . . . . . . . . . . . . . 21		7. Loss Recovery . . . . . . . . . . . . . . . . . . . . . . . . 23
	8. Transmission of Partial Content . . . . . . . . . . . . . . . 22		7.1. Forward Error Correction . . . . . . . . . . . . . . . . 23
	9. Protocol Identifier . . . . . . . . . . . . . . . . . . . . . 22		7.2. Unicast Repair . . . . . . . . . . . . . . . . . . . . . 24
	9.1. Draft Version Identification . . . . . . . . . . . . . . 22		8. Transmission of Partial Content . . . . . . . . . . . . . . . 24
	10. Discovery of Multicast QUIC Sessions . . . . . . . . . . . . 23		9. Protocol Identifier . . . . . . . . . . . . . . . . . . . . . 25
	10.1. Source-specific Multicast Advertisement . . . . . . . . 24		9.1. Draft Version Identification . . . . . . . . . . . . . . 25
	10.2. Session Parameter Advertisement . . . . . . . . . . . . 24		10. Discovery of Multicast QUIC Sessions . . . . . . . . . . . . 25
	10.2.1. Version . . . . . . . . . . . . . . . . . . . . . . 24		10.1. Source-specific Multicast Advertisement . . . . . . . . 26
	10.2.2. Cipher Suite . . . . . . . . . . . . . . . . . . . . 24		10.2. Session Parameter Advertisement . . . . . . . . . . . . 27
	10.2.3. Session Key . . . . . . . . . . . . . . . . . . . . 25		10.2.1. Version . . . . . . . . . . . . . . . . . . . . . . 27
	10.2.4. Session Identification . . . . . . . . . . . . . . . 25		10.2.2. Cipher Suite . . . . . . . . . . . . . . . . . . . . 27
	10.2.5. Session Idle Timeout Period . . . . . . . . . . . . 25		10.2.3. Session Key . . . . . . . . . . . . . . . . . . . . 27
	10.2.6. Stream Concurrency . . . . . . . . . . . . . . . . . 26		10.2.4. Session Cipher Initialization Vector . . . . . . . . 28
	10.2.7. Session Peak Flow Rate . . . . . . . . . . . . . . . 26		10.2.5. Session Identification . . . . . . . . . . . . . . . 28
	11. Security and Privacy Considerations . . . . . . . . . . . . . 26		10.2.6. Session Idle Timeout Period . . . . . . . . . . . . 28
	11.1. Pervasive Monitoring . . . . . . . . . . . . . . . . . . 27		10.2.7. Resource Concurrency . . . . . . . . . . . . . . . . 29
	11.1.1. Large-scale Data Gathering and Correlation . . . . . 27		10.2.8. Session Peak Flow Rate . . . . . . . . . . . . . . . 29
	11.1.2. Changing Content . . . . . . . . . . . . . . . . . . 27		10.2.9. Digest Algorithm . . . . . . . . . . . . . . . . . . 29
	11.2. Protection of Discovery Mechanism . . . . . . . . . . . 28		10.2.10. Signature Algorithm . . . . . . . . . . . . . . . . 30
	11.3. Spoofing . . . . . . . . . . . . . . . . . . . . . . . . 28		11. Security and Privacy Considerations . . . . . . . . . . . . . 30
	11.3.1. Spoofed Ack Attacks . . . . . . . . . . . . . . . . 28		11.1. Pervasive Monitoring . . . . . . . . . . . . . . . . . . 31
	11.3.2. Sender Spoofing . . . . . . . . . . . . . . . . . . 28		11.1.1. Large-scale Data Gathering and Correlation . . . . . 31
	11.3.3. Receiver Spoofing . . . . . . . . . . . . . . . . . 29		11.1.2. Changing Content . . . . . . . . . . . . . . . . . . 31
	11.4. Replay Attacks . . . . . . . . . . . . . . . . . . . . . 29		11.2. Protection of Discovery Mechanism . . . . . . . . . . . 32
	11.5. Message Deletion . . . . . . . . . . . . . . . . . . . . 29		11.3. Spoofing . . . . . . . . . . . . . . . . . . . . . . . . 32
	11.6. Denial of Service . . . . . . . . . . . . . . . . . . . 29		11.3.1. Spoofed Ack Attacks . . . . . . . . . . . . . . . . 32
	11.6.1. Unprotected Frames and Packets . . . . . . . . . . . 29		11.3.2. Sender Spoofing . . . . . . . . . . . . . . . . . . 32
	11.6.2. Network Performance Degradation . . . . . . . . . . 30		11.3.3. Receiver Spoofing . . . . . . . . . . . . . . . . . 32
	11.6.3. Unicast Repair Stampeding Herd . . . . . . . . . . . 30		11.4. Replay Attacks . . . . . . . . . . . . . . . . . . . . . 33
	11.7. Receiver Resource Usage . . . . . . . . . . . . . . . . 30		11.5. Message Deletion . . . . . . . . . . . . . . . . . . . . 33
	11.8. Unicast Repair Information Leakage . . . . . . . . . . . 30		11.6. Denial of Service . . . . . . . . . . . . . . . . . . . 33
	12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31		11.6.1. Unprotected Frames and Packets . . . . . . . . . . . 33
	12.1. Registration of Protocol Identification String . . . . . 31		11.6.2. Network Performance Degradation . . . . . . . . . . 34
	12.2. Registration of Alt-Svc parameters . . . . . . . . . . . 31		11.6.3. Unicast Repair Stampeding Herd . . . . . . . . . . . 34
	12.2.1. Source Address . . . . . . . . . . . . . . . . . . . 31		11.7. Receiver Resource Usage . . . . . . . . . . . . . . . . 34
	12.2.2. Cipher Suite . . . . . . . . . . . . . . . . . . . . 32		11.8. Unicast Repair Information Leakage . . . . . . . . . . . 34
	12.2.3. Key . . . . . . . . . . . . . . . . . . . . . . . . 32		12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35
	12.2.4. Session Identifier . . . . . . . . . . . . . . . . . 32		12.1. Registration of Protocol Identification String . . . . . 35
	12.2.5. Session Idle Timeout . . . . . . . . . . . . . . . . 32		12.2. Registration of Alt-Svc parameters . . . . . . . . . . . 35
	12.2.6. Maximum Concurrent Resources . . . . . . . . . . . . 32		12.2.1. Source Address . . . . . . . . . . . . . . . . . . . 35
	12.2.7. Peak Flow Rate . . . . . . . . . . . . . . . . . . . 32		12.2.2. Cipher Suite . . . . . . . . . . . . . . . . . . . . 35
	13. References . . . . . . . . . . . . . . . . . . . . . . . . . 32		12.2.3. Key . . . . . . . . . . . . . . . . . . . . . . . . 36
	13.1. Normative References . . . . . . . . . . . . . . . . . . 32		12.2.4. Initialization Vector . . . . . . . . . . . . . . . 36
	13.2. Informative References . . . . . . . . . . . . . . . . . 34		12.2.5. Session Identifier . . . . . . . . . . . . . . . . . 36
	Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 36		12.2.6. Session Idle Timeout . . . . . . . . . . . . . . . . 36
	Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 36		12.2.7. Maximum Concurrent Resources . . . . . . . . . . . . 36
	B.1. Session Advertisement . . . . . . . . . . . . . . . . . . 36		12.2.8. Peak Flow Rate . . . . . . . . . . . . . . . . . . . 36
	B.1.1. Source-specific Multicast QUIC Session . . . . . . . 36		12.2.9. Digest Algorithm . . . . . . . . . . . . . . . . . . 36
			12.2.10. Signature Algorithm . . . . . . . . . . . . . . . . 36
			13. References . . . . . . . . . . . . . . . . . . . . . . . . . 37
			13.1. Normative References . . . . . . . . . . . . . . . . . . 37
			13.2. Informative References . . . . . . . . . . . . . . . . . 38
			Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 40
			Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 40
			B.1. Session Advertisement . . . . . . . . . . . . . . . . . . 40
			B.1.1. Source-specific Multicast QUIC Session . . . . . . . 40
	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 . . . . . . . . . . 36		Encryption using a Symmetric Key . . . . . . . . . . 41
	B.2. Resource Transfer . . . . . . . . . . . . . . . . . . . . 37		B.1.3. Source-specific Multicast QUIC Session with Transport
	B.2.1. Transfer without Content Integrity or Authenticity . 37		Encryption, Content Integrity and Authenticity . . . 41
			B.2. Resource Transfer . . . . . . . . . . . . . . . . . . . . 42
			B.2.1. Transfer without Content Integrity or Authenticity . 42
	B.2.2. Transfer of Partial Content without Content Integrity		B.2.2. Transfer of Partial Content without Content Integrity
	or Authenticity . . . . . . . . . . . . . . . . . . . 37		or Authenticity . . . . . . . . . . . . . . . . . . . 42
	B.2.3. Transfer with Content Integrity and without		B.2.3. Transfer with Content Integrity and without
	Authenticity . . . . . . . . . . . . . . . . . . . . 38		Authenticity . . . . . . . . . . . . . . . . . . . . 43
	B.2.4. Partial Transfer with Content Integrity and without		B.2.4. Partial Transfer with Content Integrity and without
	Authenticity . . . . . . . . . . . . . . . . . . . . 39		Authenticity . . . . . . . . . . . . . . . . . . . . 44
	B.2.5. Transfer with Content Integrity and Authenticity . . 39		B.2.5. Transfer with Content Integrity and Authenticity . . 44
	B.2.6. Partial Transfer with Content Integrity and		B.2.6. Partial Transfer with Content Integrity and
	Authenticity . . . . . . . . . . . . . . . . . . . . 40		Authenticity . . . . . . . . . . . . . . . . . . . . 45
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41		Appendix C. Changelog . . . . . . . . . . . . . . . . . . . . . 46
			C.1. Since draft-pardue-quic-http-mcast-00 . . . . . . . . . . 46
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47
	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 6, line 44 ¶		skipping to change at page 7, line 4 ¶
	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 HTTP/2 "SETTINGS"		messages) and HTTP-specific settings (conveyed in "SETTINGS" HTTP/2
	frames). Such parameters may be required or optional and may be used		frames). Such parameters may be required or optional and may be used
	by either endpoint to control the characteristics of connection		by either endpoint to control the characteristics of connection
	usage.		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
	skipping to change at page 7, line 28 ¶		skipping to change at page 7, line 37 ¶
	lifecycle of any particular endpoint. Multicast receivers or senders		lifecycle of any particular endpoint. Multicast receivers or senders
	that take part in a session are called participants. The state of a		that take part in a session are called participants. The state of a
	session is influenced by the actions of participants. The loose		session is influenced by the actions of participants. The loose
	coupling of participants means that they are unlikely to have a		coupling of participants means that they are unlikely to have a
	consistent shared view of the current state of a session. There is		consistent shared view of the current state of a session. There is
	no requirement for a participant to know the session state and the		no requirement for a participant to know the session state and the
	present document does not define a method to explicitly determine it.		present document does not define a method to explicitly determine it.
	The definitions of session states provided below are intended to		The definitions of session states provided below are intended to
	assist higher-level operational treatment of sessions:		assist higher-level operational treatment of sessions:
	o Idle: the session has no participants and is ready to accept them.		o Quiescent: the session has no participants and is ready to accept
			them.
	o Half-established: the session has a participant.		o Half-established: the session has a participant.
	o Fully-established: the session has a sender and at least one		o Fully-established: the session has a sender and at least one
	receiver participant.		receiver participant.
	o Finished: the session has ended, and there are no participants.		o Finished: the session has ended, and there are no participants.
	Permitted states transitions are shown in Figure 1 below.		Permitted states transitions are shown in Figure 1 below.
	The transmission of QUIC packets is expected to occur only during the		The transmission of QUIC packets is expected to occur only during the
	Half-Established and Fully-Established states.		Half-Established and Fully-Established states.
	+------+ +------------------+ +-------------------+		+-----------+ +------------------+ +-------------------+
	| |-------->| |------->| |		| |-------->| |------->| |
	| Idle | | Half-Established | | Fully-Established |		| Quiescent | | Half-Established | | Fully-Established |
	| |<--------| |<-------| |		| |<--------| |<-------| |
	+------+ +------------------+ +-------------------+		+-----------+ +------------------+ +-------------------+
	| |		| |
	| v		| v
	| +----------+		| +----------+
	| | |		| | |
	+---------------->| Finished |		+------------------>| Finished |
	| |		| |
	+----------+		+----------+
	Figure 1: Multicast QUIC session states		Figure 1: Multicast QUIC session states
	2.1.1. Session Establishment		2.1.1. Session Establishment
	A session begins in the Idle state. A typical session establishment		A session begins in the Quiescent state. A typical session
	sequence would see the transition from Idle to Half-Established when		establishment sequence would see the transition from Quiescent to
	a sender joins the session. The transition from Half-Established to		Half-Established when a sender joins the session. The transition
	Fully-Established occurs when at least one receiver joins the		from Half-Established to Fully-Established occurs when at least one
	session.		receiver joins the session.
	It is equally valid for a receiver to join a session in the Idle		It is equally valid for a receiver to join a session in the Quiescent
	state, triggering the transition to Half-Established. In this case,		state, triggering the transition to Half-Established. In this case,
	the transition to Fully-Established takes place only when a sender		the transition to Fully-Established takes place only when a sender
	joins the session.		joins the session.
	2.1.2. Session Termination		2.1.2. Session Termination
	A session enters the Finished state when all participants leave it.		A session enters the Finished state when all participants leave it.
	The methods for leaving a session are either explicit shutdown		The methods for leaving a session are either explicit shutdown
	(Section 5.5), implicit shutdown (i.e. idle timeout, Section 3.4) or		(Section 5.5), implicit shutdown (i.e. idle timeout, Section 3.4) or
	migration away (described in the next section).		migration away (described in the next section).
	In a typical case, a session that is in the Fully-Established state		In a typical case, a session that is in the Fully-Established state
	would be closed in two stages. In the first stage the sender sends		would be closed in two stages. In the first stage the sender sends
	explicit shutdown messages to the multicast group and subsequently		explicit shutdown messages to the multicast group and subsequently
	stops transmitting packets. This causes the session to transition		stops transmitting packets. This causes the session to transition
	from Fully-Established to Half-Established. In the second stage,		from Fully-Established to Half-Established. In the second stage,
	receivers that have received explicit shutdown messages leave the		receivers that have received explicit shutdown messages leave the
	multicast group. Once all receivers have left the session it		multicast group. Once all receivers have left the session it
	transitions from Half-Established to Finished.		transitions from Half-Established to Finished.
	The transition from Idle to Finished could also occur in response to		The transition from Quiescent to Finished could also occur in
	out-of-band actions, for example the availability of a session being		response to out-of-band actions, for example the availability of a
	withdrawn without any participants having made use of it.		session being withdrawn without any participants having made use of
			it.
	2.1.3. Session Migration		2.1.3. Session Migration
	Endpoints MAY migrate between multicast QUIC sessions (for example,		Endpoints MAY migrate between multicast QUIC sessions (for example,
	to make use of alternate session parameters that are preferred).		to make use of alternate session parameters that are preferred).
	Session migration requires participants to leave the current session		Session migration requires participants to leave the current session
	and join the new session. These actions affect the state of the		and join the new session. These actions affect the state of the
	respective sessions as explained above.		respective sessions as explained above.
	The discovery of multicast QUIC sessions is described in Section 3.		The discovery of multicast QUIC sessions is described in Section 3.
	skipping to change at page 10, line 13 ¶		skipping to change at page 10, line 13 ¶
	Assignment of Session ID is considered out of this document's scope.		Assignment of Session ID is considered out of this document's scope.
	The Session ID is carried in the Connection ID field of the QUIC		The Session ID is carried in the Connection ID field of the QUIC
	packet (see Section 4.3).		packet (see Section 4.3).
	A multicast sender participating in a session MUST send QUIC packets		A multicast sender participating in a session MUST send QUIC packets
	with a matching Session ID. A multicast receiver participating in a		with a matching Session ID. A multicast receiver participating in a
	session MUST validate that the Session ID of received QUIC packets		session MUST validate that the Session ID of received QUIC packets
	matches that advertised in the session parameters (Section 3,		matches that advertised in the session parameters (Section 3,
	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 leave the session 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 Crypto and Transport handshake (see [QUIC-TRANSPORT],
	[QUIC-TLS] and [QUICCrypto]) sets out methods to achieve the goals of		[QUIC-TLS] and [QUICCrypto]) sets out methods to achieve the goals of
	authenticated key exchange and record protection between two		authenticated key exchange and record protection between two
	endpoints forming a QUIC connection. The design facilitates low-		endpoints forming a QUIC connection. The design facilitates low-
	latency connection; 1-RTT or 0-RTT. The Crypto handshake [QUIC-TLS]		latency connection; 1-RTT or 0-RTT. The Crypto handshake [QUIC-TLS]
	reserves QUIC stream 1 for TLS 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 1 (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
	in use for that session. Participants SHOULD leave any session that		in use for that session. Participants MAY leave any session that
	fails to successfully match anticipated security characteristics.		fails to successfully match anticipated security characteristics.
	3. Session Advertisement		3. Session Advertisement
	In this specification, connection negotiation is replaced with a		In this specification, connection negotiation is replaced with a
	session advertisement mechanism based on HTTP Alternative Services		session advertisement mechanism based on HTTP Alternative Services
	(Alt-Svc) [RFC7838]. This document specifies how the parameters of a		(Alt-Svc) [RFC7838]. This document specifies how the parameters of a
	multicast QUIC session are expressed as Alt-Svc parameters. The		multicast QUIC session are expressed as Alt-Svc parameters. The
	following sections provide a high-level view of these; further		following sections provide a high-level view of these; further
	details are provided in Section 10.2, with examples provided in		details are provided in Section 10.2, with examples provided in
	skipping to change at page 11, line 43 ¶		skipping to change at page 11, line 43 ¶
	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 but with the additional
	constraint that the parameter MUST appear exactly once: it is not		constraint that the parameter MUST appear exactly once: it is not
	optional and the parameter MUST NOT be repeated.		optional and the parameter MUST NOT be repeated.
	This mechanism replaces the use of the Version field in the QUIC		This mechanism replaces the use of the Version field in the QUIC
	packet (see Section 4.2).		packet long header (see Section 4.2).
	A multicast sender participating in a session MUST send HTTP messages		A multicast sender participating in a session MUST send QUIC packets
	in the format corresponding to the advertised version. If the sender		and frames in the format corresponding to the advertised version. If
	does not support the advertised version it MUST NOT send any data. A		the sender does not support the advertised version it MUST NOT send
	receiver MUST NOT join a session where the "quic" parameter is		any data. A receiver MUST NOT join a session where the "quic"
	absent. A receiver SHOULD NOT join a session for which it does not		parameter is absent. A receiver SHOULD NOT join a session for which
	support the advertised version, in order to avoid wasting processing		it does not support the advertised version, in order to avoid wasting
	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:
	o Cipher suite negotiation is replaced with a "cipher suite" session		o Cipher suite negotiation is replaced with a "cipher suite" session
	skipping to change at page 12, line 29 ¶		skipping to change at page 12, line 29 ¶
	multicast QUIC session is assumed to be operating with cipher		multicast QUIC session is assumed to be operating with cipher
	suite 0x00,0x00 (NULL_WITH_NULL_NULL).		suite 0x00,0x00 (NULL_WITH_NULL_NULL).
	o Key exchange is replaced with a "key" session parameter, which is		o Key exchange is replaced with a "key" session parameter, which is
	advertised as the Alt-Svc parameter "key" (Section 10.2.3). The		advertised as the Alt-Svc parameter "key" (Section 10.2.3). The
	parameter carries a variable-length hex-encoded key for use with		parameter carries a variable-length hex-encoded key for use with
	the session cipher suite. In the absence of the "key" parameter,		the session cipher suite. In the absence of the "key" parameter,
	the key may be available via an out-of-band method not described		the key may be available via an out-of-band method not described
	in this document.		in this document.
			o 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. In
			the absence of the "iv" parameter, the IV may be available via an
			out-of-band method not described in this document.
	In order to protect themselves, endpoints SHOULD NOT participate in		In order to protect themselves, endpoints SHOULD NOT participate in
	sessions for which they cannot establish reasonable confidence over		sessions for which they cannot establish reasonable confidence over
	the cipher suite or key in use for that session. Endpoints SHOULD		the cipher suite or key in use for that session. Endpoints SHOULD
	leave any sessions which fail to successfully match anticipated		leave any sessions which fail to successfully match anticipated
	security characteristics.		security characteristics.
	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.4). 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.
	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 QUIC "ICSL"		a period of idleness (lack of network activity). The required QUIC
	required negotiation parameter provides a means for endpoints to		TransportParameter "idle_timeout" provides a means for endpoints to
	define a timeout period, the default period being 30 seconds. This		specify the timeout period. This document defines a "session idle
	document defines a "session idle timeout" session parameter, which is		timeout" session parameter, which is advertised as the Alt-Svc
	advertised as the Alt-Svc parameter "session-idle-timeout"		parameter "session-idle-timeout" (Section 10.2.6). This session
	(Section 10.2.5). This session parameter mimics the behaviour of		parameter mimics the behaviour of "idle_timeout", providing a means
	"ICSL", providing a means for multicast QUIC sessions to define their		for multicast QUIC sessions to define their own idle timeout periods.
	own idle timeout periods.
			Session advertisements that omit the Alt-Svc parameter "session-idle-
			timeout" imply that the default timeout period is in use. The
			default value is 30 seconds.
	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
	"CONNECTION_CLOSE" QUIC frame is sent.		"CONNECTION_CLOSE" QUIC 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
	parameters "SFCW" and "CFCW". In a unidirectional multicast		TransportParameters "initial_max_data" and "initial_max_stream_data".
	environment, such a scheme is infeasible. This document defines a		In a unidirectional multicast environment, such a scheme is
	"peak flow rate" session parameter, expressed in units of bits per		infeasible. This document defines a "peak flow rate" session
	second, which is advertised as the Alt-Svc parameter "peak-flow-rate"		parameter, expressed in units of bits per second, which is advertised
	(Section 10.2.7). This replaces "CFCW" and indicates the maximum bit		as the Alt-Svc parameter "peak-flow-rate" (Section 10.2.8). This
	rate of "STREAM" QUIC frame payloads transmitted on all multicast		replaces "initial_max_data" and "initial_max_stream_data" completely,
	groups comprising the session.		instead indicating the maximum bit rate of "STREAM" QUIC frame
			payloads transmitted on all multicast groups comprising the session.
			Session advertisements that omit the Alt-Svc parameter "peak-flow-
			rate" 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
	The QUIC handshake required parameter "MSPC" defines the maximum		[QUIC-TRANSPORT] considers concurrency in terms of the number of
	number of concurrent streams a conventional QUIC endpoint can		active incoming streams, which is varied by the receiving endpoint
	initiate per connection. In a unidirectional multicast environment,		adjusting the maximum stream ID. The initial value of maximum stream
	there is no way for a receiver to specify the limit. This document		ID is controlled by the required QUIC TransportParameter
	specifies a new "maximum concurrent resources" session parameter,		"initial_max_stream_id". It is increased during the lifetime of a
	which is advertised as the Alt-Svc parameter "max-concurrent-		QUIC connection by the "MAX_STREAM_ID" QUIC frame. In a
	resources" (Section 10.2.6). This parameter replaces "MSPC". It		unidirectional multicast environment, there is no way for a receiver
	advertises the maximum number of concurrent active resources		to specify the limit nor increase it. Therefore the maximum stream
	generated by a sender in a given multicast QUIC session.		ID mechanism is not used to manage concurrency in multicast QUIC.
			The "STREAM_ID_NEEDED" QUIC frame MAY be sent by a sending
			participant but it will have no effect. This frame SHALL be ignored
			by receiving participants.
			This document specifies a "maximum concurrent resources" session
			parameter, which is advertised as the Alt-Svc parameter "max-
			concurrent-resources" (Section 10.2.7). This parameter replaces
			"initial_max_stream_id". It advertises the maximum number of
			concurrent active resources generated by a sender in a given
			multicast QUIC session.
			Session advertisements that omit the Alt-Svc parameter "maximum
			concurrent resources" 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		advertised "max-concurrent-resources" to be exceeded. A receiver MAY
	SHOULD leave any session where the advertised limit is exceeded, in		leave any session where the advertised limit is exceeded, in order to
	order to protect itself from denial-of-service attacks.		protect itself from denial-of-service attacks.
	3.7. Connection Options		3.7. Additional TransportParameter Considerations
	*Authors' Note:* Conventional QUIC Connection Options (COPTs) are		*Authors' Note:* Google QUIC Connection Options (COPTs) are no
	to be defined in WG documents. This section will track		longer referred to in WG documents. This section will consider
	developments and will be updated accordingly.		TransportParameters, tracking developments and issues that may
			arise.
			3.8. Digest Algorithm
			A method to provide content integrity is described in Section 6.1.
			This specifies the means to convey a value computed by a particular
			digest algorithm. The identity of the selected algorithm is also
			indicated. Valid digest algorithms are collected in the IANA HTTP
			Digest Algorithm Values registry (http://www.iana.org/assignments/
			http-dig-alg/http-dig-alg.xhtml#http-dig-alg-1).
			This document specifies a "digest algorithm" session parameter, which
			is advertised as the Alt-Svc parameter "digest-algorithm"
			(Section 10.2.9).
			*Authors' Note:* Section 6.1 contains an author's note on the
			potential for content integrity to become mandatory. This section
			will be updated in line with the outcome of that decision.
			Repetition of the "digest algorithm" parameter in a single
			advertisement describes an algorithm set that MAY be used across the
			session. Session 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 algorithm set is unrestricted, i.e. a sender may vary the
			algorithm as it so chooses. This may lead to undesirable results
			if receivers do not support a chosen algorithm.
			Advertising the algorithm set for a session gives receivers the
			opportunity to selectively join sessions where the algorithms are
			known to be supported. This may help to mitigate latency issues in
			the receiver resulting from joining a session only to discover some
			of its parameters are not supported.
			A multicast sender participating in a session MUST NOT use algorithms
			outside the signalled digest algorithm set. A receiver MAY leave any
			session where an algorithm outside the digest algorithm set is used.
			3.9. Signature Algorithm
			A method to provide content authenticity is described in Section 6.2.
			This specifies the means to convey a value computed by a particular
			signature algorithm. The identity of the selected algorithm is also
			indicated. Valid signature algorithms are collected in the IANA
			Signature Algorithms registry (http://www.iana.org/assignments/
			signature-algorithms).
			This document specifies a "signature algorithm" session parameter,
			which is advertised as the Alt-Svc parameter "signature-algorithm"
			(Section 10.2.10).
			*Authors' Note:* Section 6.2 contains an author's note on the
			potential for content authenticity to become mandatory. This
			section will be updated in line with the outcome of that decision.
			Repetition of the "signature algorithm" parameter in a single
			advertisement describes an algorithm set that MAY be used across the
			session. 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 algorithm set is unrestricted i.e. a sender may vary the
			algorithm as it so chooses. This may lead to undesirable results
			if receivers do not support a chosen algorithm.
			Advertising the algorithm set for a session gives receivers the
			opportunity to selectively join sessions where the algorithms are
			known to be supported. This may help to mitigate latency issues in
			the receiver resulting from joining a session only to discover some
			of its parameters are not supported.
			A multicast sender participating in a session MUST NOT use algorithms
			outside the signalled signature algorithm set. A receiver MAY leave
			any session where an algorithm outside the signature algorithm set is
			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 draft-ietf-quic-transport-01. The		This section is based on our best understanding of draft-ietf-
	authors will track developments and will update this section		quic-transport-04. The authors will track developments and will
	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 8 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,
	considerations should be given towards 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. Version Negotiation
	Endpoints implementing this specification MUST NOT send QUIC packets		Endpoints implementing this specification MUST only send QUIC packets
	containing a Version field and MUST NOT set the "VERSION" flag in the		with the short header format. This header format omits a Version
	QUIC packet header.		field.
			*Authors' Note:* The authors welcome suggestions for conveying the
			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
	Senders MUST NOT send any QUIC frames on QUIC stream 1. Receivers		Senders MUST NOT send any QUIC frames on QUIC stream 0. Receivers
	MUST ignore QUIC frames sent on stream 1.		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 the "WINDOW_UPDATE" QUIC frame.		and endpoints manage this by sending "MAX_DATA" or "MAX_STREAM_DATA"
	When a sender is blocked from sending flow-controlled frames, it		QUIC frames as required. When a sender is blocked from sending flow-
	sends an informational "BLOCKED" QUIC frame.		controlled frames, it sends an informational "BLOCKED" or
			"STREAM_BLOCKED" QUIC 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 "WINDOW_UPDATE"		information is not supported by this profile. The "MAX_DATA",
	and "BLOCKED" QUIC frames are prohibited by this profile.		"MAX_STREAM_DATA", "BLOCKED" and "STREAM_BLOCKED" QUIC frames are
	Participants MUST NOT send these frame types. Reception of these		prohibited by this profile. Participants MUST NOT send these frame
	frame types MUST be handled as described in Section 4.10.		types. Reception of these frame types MUST be handled as described
			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 "STREAM" QUIC frame, or
	by sending a "RST_STREAM" QUIC frame (as specified in		by sending a "RST_STREAM" QUIC 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 "RST_STREAM"
	to the multicast group.		to the multicast group.
	skipping to change at page 16, line 20 ¶		skipping to change at page 18, line 32 ¶
	Receiving participants MUST NOT make any attempt to send "PING"		Receiving participants MUST NOT make any attempt to send "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 "ACK" QUIC 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.
	The "STOP_WAITING" QUIC frame is also prohibited by this profile.		Section 7 specifies alternative strategies for loss recovery.
	Participants MUST NOT make any attempt to send this frame type.
	Reception of this frame MUST be handled as described in Section 4.10.
	{#loss-recovery} 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:
	Public Reset, Version Negotiation.		0-RTT Protected, 1-RTT Protected (key phase 0), 1-RTT Protected (key
			phase 1), Client Cleartext, Client Initial, Public Reset, Server
			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", "STOP_WAITING",		"ACK", "BLOCKED", "CONNECTION_CLOSE", "GOAWAY", "MAX_DATA",
	"WINDOW_UPDATE".		"MAX_STREAM_DATA", "STREAM_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 draft-ietf-quic-http-01. The		change. This section is based on our best understanding of draft-
	authors will track developments and will update this section		ietf-quic-http-04. The authors will track developments and will
	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.5 of [QUIC-HTTP]. Section 5.2 below applies an additional		Section 4.4 of [QUIC-HTTP]. Section 5.2 below applies an additional
	constraint on the use of server push. A multicast sender		constraint on the use of server push. A multicast sender
	participating in a session pushes resources as a series of QUIC		participating in a session pushes resources as a series of "STREAM"
	"STREAM" frames carrying HTTP/2 "PUSH_PROMISE", "HEADERS" and body		QUIC frames carrying HTTP/2 "PUSH_PROMISE", "HEADERS" and body data.
	data. Examples of this are provided in Appendix B.2. Senders MUST		Examples of this are provided in Appendix B.2. Senders MUST comply
	comply with the requirements of the session parameters, as described		with the requirements of the session parameters, as described earlier
	earlier in Section 3.		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 "SETTINGS" HTTP/2 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, enabled for HTTP/QUIC connections. A
	conventional HTTP/QUIC client may disable server push via an HTTP/2		conventional HTTP/QUIC client may disable server push via a
	"SETTINGS" frame but the use of that frame is prohibited by this		"SETTINGS" HTTP/2 frame but the use of that frame is prohibited by
	profile (Section 5.1). This profile mandates the use of server push,		this profile (Section 5.1). This profile mandates the use of server
	and specifies no means to disable it.		push, and specifies no means to disable it.
	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 HTTP/2 stream ID that would normally be used for the first client
	request. "PUSH_PROMISE" frames MUST reference this reserved ID.		request. "PUSH_PROMISE" frames MUST reference this reserved 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.
	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. In the context of QUIC, QPACK [QPACK] considers changes to		encoding.
	the mapping of HPACK that allow for better leverage of the transport.
	A multicast QUIC session, as described in the present document, does		A multicast QUIC session, as described in the present document, does
	not provide the assurances (receiver participation, transport		not provide the assurances (receiver participation, transport
	reliability) required to sufficiently maintain the dynamic decoding		reliability) required to sufficiently maintain the dynamic decoding
	context. Therefore, this document requires that endpoints SHALL NOT		context. Therefore, this document requires that endpoints SHALL NOT
	use dynamic indexing. It is RECOMMENDED that endpoints use static		use dynamic indexing. It is RECOMMENDED that endpoints use static
	indexing and/or Huffman encoding in order to benefit from the		indexing and/or Huffman encoding in order to benefit from the
	remaining compression methods available.		remaining compression methods available.
			*Authors' Note:* In the context of QUIC, changes to HPACK may
			allow for better leverage of the transport. QPACK [QPACK] and
			[QCRAM] 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 "PRIORITY" HTTP/2 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
	skipping to change at page 18, line 51 ¶		skipping to change at page 21, line 27 ¶
	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
	In many applications, it is important to ensure that an HTTP		In many applications, it is important to ensure that an HTTP
	representation has been received intact and has not suffered from		representation has been received intact (i.e. has not suffered from
	transmission loss, random bit errors or malicious substitution before		transmission loss or random bit errors) before passing the received
	passing the received object on to the receiving application. A		object on to the receiving application. A mechanism is therefore
	mechanism is therefore specified here to provide end-to-end content		specified here to provide end-to-end content integrity protection for
	integrity protection for HTTP representations in transit. The use of		HTTP representations in transit. The use of this content integrity
	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 "HEADERS" frame of any
	representation it transmits and a receiver MAY use this header to		representation it transmits and a receiver MAY use this header to
	validate the integrity of the received representation once it has		validate the integrity of the received representation once it has
	been reassembled. Where this validation fails, the receiver SHOULD		been reassembled. Where this validation fails, the receiver SHOULD
	discard the representation without processing it further.		discard the representation without processing it further.
	skipping to change at page 24, line 43 ¶		skipping to change at page 27, line 21 ¶
	10.2.1. Version		10.2.1. Version
	The version of QUIC supported in a multicast QUIC session is		The version of QUIC supported in a multicast QUIC session is
	advertised with the "quic" parameter. The requirements for endpoint		advertised with the "quic" parameter. The requirements for endpoint
	usage of "quic" are specified in Section 3.1.		usage of "quic" are specified in Section 3.1.
	10.2.2. Cipher Suite		10.2.2. Cipher Suite
	This document specifies the "cipher-suite" parameter for Alt-Svc,		This document specifies the "cipher-suite" parameter for Alt-Svc,
	which carries the cipher suite in use by a multicast QUIC session.		which carries the cipher suite in use by a multicast QUIC session.
	"cipher-suite" MUST be contain one of the values contained in the TLS		"cipher-suite" MUST contain one of the values contained in the TLS
	Cipher Suite Registry (http://www.iana.org/assignments/tls-		Cipher Suite Registry (http://www.iana.org/assignments/tls-
	parameters/tls-parameters.xhtml#tls-parameters-4):		parameters/tls-parameters.xhtml#tls-parameters-4):
	Syntax:		Syntax:
	cipher-suite = 4*4 HEXDIG		cipher-suite = 4*4 HEXDIG
	For example, the following specifies cipher suite 0x13,0x01		For example, the following specifies cipher suite 0x13,0x01
	("TLS_AES_128_GCM_SHA256"):		("TLS_AES_128_GCM_SHA256"):
	skipping to change at page 25, line 26 ¶		skipping to change at page 28, line 5 ¶
	key = *HEXDIG		key = *HEXDIG
	For example:		For example:
	key=4adf1eab9c2a37fd		key=4adf1eab9c2a37fd
	The requirements for endpoint usage of "key" are described in		The requirements for endpoint usage of "key" are described in
	Section 3.2.		Section 3.2.
	10.2.4. Session Identification		10.2.4. Session Cipher Initialization Vector
			This document specifies the "iv" parameter for Alt-Svc, which carries
			the cipher Initialization Vector (IV) in use by the multicast QUIC
			session.
			Syntax:
			iv = *HEXDIG
			For example:
			iv=4dbe593acb4d1577ad6ba7dc3189834e
			The requirements for endpoint usage of "iv" are described in
			Section 3.2.
			10.2.5. Session Identification
	This document defines the "session-id" parameter for Alt-Svc, which		This document defines the "session-id" parameter for Alt-Svc, which
	carries the multicast QUIC session identifier.		carries the multicast QUIC session identifier.
	Syntax:		Syntax:
	session-id = 1*16HEXDIG ; 64-bit value		session-id = 1*16HEXDIG ; 64-bit value
	For example, the following specifies session 101 (0x65 hexadecimal):		For example, the following specifies session 101 (0x65 hexadecimal):
	session-id=65		session-id=65
	The requirements for endpoint usage of "session-id" are described in		The requirements for endpoint usage of "session-id" are described in
	Section 2.3.		Section 2.3.
	10.2.5. Session Idle Timeout Period		10.2.6. Session Idle Timeout Period
	This document specifies the "session-idle-timeout" parameter for Alt-		This document specifies the "session-idle-timeout" parameter for Alt-
	Svc, which carries the idle timeout period of a multicast QUIC		Svc, which carries the idle timeout period of a multicast QUIC
	session.		session.
	Syntax:		Syntax:
	session-idle-timeout = *DIGIT ; number of seconds between 0 and 600		session-idle-timeout = *DIGIT ; number of seconds between 0 and 600
	For example, the following specifies a one-minute session idle		For example, the following specifies a one-minute session idle
	timeout period:		timeout period:
	session-idle-timeout=60		session-idle-timeout=60
	The requirements for endpoint usage of "session-idle-timeout" are		The requirements for endpoint usage of "session-idle-timeout" are
	described in Section 3.4.		described in Section 3.4.
	10.2.6. Stream Concurrency		10.2.7. Resource Concurrency
	This document specifies the "max-concurrent-resources" parameter for		This document specifies the "max-concurrent-resources" parameter for
	Alt-Svc, which expresses the maximum number of concurrent active		Alt-Svc, which expresses the maximum number of concurrent active
	resources from the sender in a multicast QUIC session.		resources from the sender in a multicast QUIC session.
			Syntax:
	max-concurrent-resources = *DIGIT ; unsigned 32-bit integer		max-concurrent-resources = *DIGIT ; unsigned 32-bit integer
	For example, the following specifies that no more than 12 (decimal)		For example, the following specifies that no more than 12 (decimal)
	resources will be concurrently active in the session:		resources will be concurrently active in the session:
	max-concurrent-resources=12		max-concurrent-resources=12
	The requirements for endpoint usage of "max-concurrent-streams" are		The requirements for endpoint usage of "max-concurrent-resources" are
	described in Section 3.6.		described in Section 3.6.
	10.2.7. Session Peak Flow Rate		10.2.8. Session Peak Flow Rate
	This parameter expresses the expected maximum transfer rate of data		This document specifies the "peak-flow-rate" parameter for Alt-Svc,
			which expresses the expected maximum aggregate transfer rate of data
	from all sources of the multicast QUIC session.		from all sources of the multicast QUIC session.
			Syntax:
	peak-flow-rate = *DIGIT ; bits per second		peak-flow-rate = *DIGIT ; bits per second
	For example, the following specifies a peak flow rate of 550 kbits/s		For example, the following specifies a peak flow rate of 550 kbits/s
	in the session:		in the session:
	peak-flow-rate=550000		peak-flow-rate=550000
	The requirements for endpoint usage of "peak-flow-rate" are described		The requirements for endpoint usage of "peak-flow-rate" are described
	in Section 3.5.		in Section 3.5.
			10.2.9. Digest Algorithm
			This document specifies the "digest-algorithm" parameter for Alt-Svc,
			which carries the digest algorithm in use by a multicast QUIC
			session. "digest-algorithm" MUST contain one of the values defined in
			the HTTP Digest Algorithm Values registry
			(https://www.iana.org/assignments/http-dig-alg/http-dig-
			alg.xhtml#http-dig-alg-1).
			Syntax:
			digest-algorithm = token
			For example, the following specifies a digest algorithm of SHA-256:
			digest-algorithm=SHA-256
			The requirements for endpoint usage of "digest-algorithm" are
			described in Section 3.8.
			10.2.10. Signature Algorithm
			This document specifies the "signature-algorithm" parameter for Alt-
			Svc, which carries the signature algorithm in use by a multicast QUIC
			session. "signature-algorithm" MUST contain one of the values defined
			in the Signature Algorithms registry
			(http://www.iana.org/assignments/signature-algorithms).
			Syntax:
			signature-algorithm = token
			For example, the following specifies a signature algorithm of SHA-
			256:
			signature-algorithm=rsa-sha256
			The requirements for endpoint usage of "signature-algorithm" are
			described in Section 3.9.
	11. Security and Privacy Considerations		11. Security and Privacy Considerations
	This document specifies a profile of QUIC and HTTP/QUIC that changes		This document specifies a profile of QUIC and HTTP/QUIC that changes
	the security model. In order to address this, application-level		the security model. In order to address this, application-level
	security methods are described in Section 6. This document does not		security methods are described in Section 6. This document does not
	preclude the use of secure multicast approaches that may provide		preclude the use of secure multicast approaches that may provide
	additional security assurances required for certain use cases.		additional security assurances required for certain use cases.
	The use of side-channel or out-of-band technologies (potentially		The use of side-channel or out-of-band technologies (potentially
	bidirectional interactions) to support multicast QUIC sessions are		bidirectional interactions) to support multicast QUIC sessions are
	skipping to change at page 28, line 31 ¶		skipping to change at page 32, line 26 ¶
	Endpoints that make use of multicast QUIC session advertisements		Endpoints that make use of multicast QUIC session advertisements
	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 12.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 "ACK" frame is
	prohibited (Section 4.9) by the present document.		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.
	skipping to change at page 29, line 7 ¶		skipping to change at page 32, line 48 ¶
	characteristics of the multicast deployment and network		characteristics of the multicast deployment and network
	infrastructure. The use of source-specific multicast [RFC4607] may		infrastructure. The use of source-specific multicast [RFC4607] may
	reduce the feasibility. The use of content authenticity		reduce the feasibility. The use of content authenticity
	(Section 6.2) may mitigate concerns for the application-level		(Section 6.2) may mitigate concerns for the application-level
	messages. However, there remains the possibility for transport-level		messages. However, there remains the possibility for transport-level
	messages to be spoofed. Multicast applications should consider		messages to be spoofed. Multicast applications should consider
	further mitigations to address this concern.		further mitigations to address this concern.
	11.3.3. Receiver Spoofing		11.3.3. Receiver Spoofing
	Client source address concerns discussed in Section 6.2.2 of		Client source address concerns discussed in Section 7.5 of
	[QUIC-TRANSPORT] are out of scope because the connection		[QUIC-TRANSPORT] are out of scope because the connection
	establishment is replaced with session establishment in the present		establishment is replaced with session establishment in the present
	document. Further, the impact that spoofed receivers would have on		document. Further, the impact that spoofed receivers would have on
	the sender is minimal. The impact of malicious participants on the		the sender is minimal. The impact of malicious participants on the
	network is discussed in Section 11.6.2.		network is discussed in Section 11.6.2.
	11.4. Replay Attacks		11.4. Replay Attacks
	Conventional QUIC strategies for protecting against replay attacks		Conventional QUIC strategies for protecting against replay attacks
	apply similarly here.		apply similarly here.
	skipping to change at page 29, line 44 ¶		skipping to change at page 33, line 37 ¶
	receiver to fail in construction of a content object) is mitigated by		receiver to fail in construction of a content object) is mitigated by
	falling back to a unicast service. Considerations for how this may		falling back to a unicast service. Considerations for how this may
	affect the performance of the unicast service are given in		affect the performance of the unicast service are given in
	Section 11.6.3.		Section 11.6.3.
	11.6. Denial of Service		11.6. Denial of Service
	11.6.1. Unprotected Frames and Packets		11.6.1. Unprotected Frames and Packets
	The handling of unprotected QUIC packets is discussed in section		The handling of unprotected QUIC packets is discussed in section
	7.1.4 of [QUIC-TLS]. The profile described in the present document		9.1.4 of [QUIC-TLS]. The profile described in the present document
	provides the means for a multicast sender to protect QUIC packets		provides the means for a multicast sender to protect QUIC packets
	with a shared key, which is not a strong protection. The weak		with a shared key, which is not a strong protection. The weak
	protection of QUIC packets could present a denial-of-service risk.		protection of QUIC packets could present a denial-of-service risk.
	To mitigate the impact of handling such QUIC packets, certain frames		To mitigate the impact of handling such QUIC packets, certain frames
	and packets are prohibited as described in (Section 4.10 and		and packets are prohibited as described in (Section 4.10 and
	Section 5.7).		Section 5.7).
	The frame types that are allowed by this profile do not present a		The frame types that are allowed by this profile do not present a
	risk of denial of service. Concerns over authenticity and integrity		risk of denial of service. Concerns over authenticity and integrity
	are addressed by the application-layer protection mechanisms		are addressed by the application-layer protection mechanisms
	described in Section 6.		described in Section 6.
	11.6.2. Network Performance Degradation		11.6.2. Network Performance Degradation
	The possibility for malfunctioning or malicious participants to		The possibility for malfunctioning or malicious participants to
	degrade the network is a broad issue and considered out of scope for		degrade the network is a broad issue and considered out of scope for
	this document. Guidelines and concerns discussed in UDP Best		this document. Guidelines and concerns discussed in UDP Best
	Practices [I-D.ietf-tsvwg-rfc5405bis] and other sources apply equally		Practices [RFC8085] and other sources apply equally here. This
	here. This specification does not preclude the use of network		specification does not preclude the use of network performance
	performance degradation mitigation solutions such as network circuit		degradation mitigation solutions such as network circuit breakers.
	breakers.
	11.6.3. Unicast Repair Stampeding Herd		11.6.3. Unicast Repair Stampeding Herd
	Deployments that support the unicast repair mechanism described in		Deployments that support the unicast repair mechanism described in
	Section 7.2 should be aware that a triggering of this behaviour		Section 7.2 should be aware that a triggering of this behaviour
	(either deliberate, planned or unplanned) in a large population of		(either deliberate, planned or unplanned) in a large population of
	multicast receivers may cause a stampeding herd of client requests to		multicast receivers may cause a stampeding herd of client requests to
	the unicast repair service. Service operators SHOULD mitigate the		the unicast repair service. Service operators SHOULD mitigate the
	impact of stampeding herd on their deployment.		impact of stampeding herd on their deployment.
	skipping to change at page 32, line 17 ¶		skipping to change at page 36, line 11 ¶
	Parameter name: cipher-suite		Parameter name: cipher-suite
	Specification: This document, Section 10.2.2		Specification: This document, Section 10.2.2
	12.2.3. Key		12.2.3. Key
	Parameter name: key		Parameter name: key
	Specification: This document, Section 10.2.3		Specification: This document, Section 10.2.3
	12.2.4. Session Identifier		12.2.4. Initialization Vector
	Parameter name: session-id		Parameter name: iv
	Specification: This document, Section 10.2.4		Specification: This document, Section 10.2.4
	12.2.5. Session Idle Timeout		12.2.5. Session Identifier
	Parameter name: session-idle-timeout		Parameter name: session-id
	Specification: This document, Section 10.2.5		Specification: This document, Section 10.2.5
	12.2.6. Maximum Concurrent Resources		12.2.6. Session Idle Timeout
	Parameter name: max-concurrent-resources		Parameter name: session-idle-timeout
	Specification: This document, Section 10.2.6		Specification: This document, Section 10.2.6
	12.2.7. Peak Flow Rate		12.2.7. Maximum Concurrent Resources
	Parameter name: peak-flow-rate		Parameter name: max-concurrent-resources
	Specification: This document, Section 10.2.7		Specification: This document, Section 10.2.7
			12.2.8. Peak Flow Rate
			Parameter name: peak-flow-rate
			Specification: This document, Section 10.2.8
			12.2.9. Digest Algorithm
			Parameter name: digest-algorithm
			Specification: This document, Section 10.2.9
			12.2.10. Signature Algorithm
			Parameter name: signature-algorithm
			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-06 (work in progress), January		cavage-http-signatures-07 (work in progress), July 2017.
	2017.
	[QUIC-HTTP]		[QUIC-HTTP]
	Bishop, M., Ed., "Hypertext Transfer Protocol (HTTP) over		Bishop, M., Ed., "Hypertext Transfer Protocol (HTTP) over
	QUIC".		QUIC", draft-ietf-quic-http-04 (work in progress).
	[QUIC-RECOVERY]		[QUIC-RECOVERY]
	Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection		Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection
	and Congestion Control".		and Congestion Control", draft-ietf-quic-recovery-04 (work
			in progress).
	[QUIC-TLS]		[QUIC-TLS]
	Thomson, M., Ed. and S. Turner, Ed, Ed., "Using Transport		Thomson, M., Ed. and S. Turner, Ed, Ed., "Using Transport
	Layer Security (TLS) to Secure QUIC".		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".		Multiplexed and Secure Transport", draft-ietf-quic-
			transport-04 (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,
	<http://www.rfc-editor.org/info/rfc2119>.		<http://www.rfc-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>.		<http://www.rfc-editor.org/info/rfc3230>.
	skipping to change at page 34, line 25 ¶		skipping to change at page 38, line 40 ¶
	Transfer Protocol Version 2 (HTTP/2)", RFC 7540,		Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
	DOI 10.17487/RFC7540, May 2015,		DOI 10.17487/RFC7540, May 2015,
	<http://www.rfc-editor.org/info/rfc7540>.		<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, <http://www.rfc-editor.org/info/rfc7838>.
	13.2. Informative References		13.2. Informative References
	[I-D.ietf-tsvwg-rfc5405bis]		[QCRAM] Krasic, C., Ed., "Header Compression for HTTP over QUIC",
	Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage		draft-krasic-quic-qcram-02 (work in progress).
	Guidelines", draft-ietf-tsvwg-rfc5405bis-19 (work in
	progress), October 2016.
	[QPACK] Bishop, M., Ed., "HTTP over QUIC - Mapping and Header		[QPACK] Bishop, M., Ed., "Header Compression for HTTP/QUIC",
	Compression".		draft-bishop-quic-http-and-qpack-02 (work in progress).
	[QUICCrypto]		[QUICCrypto]
	Langley, A. and W. Chang, "QUIC Crypto", May 2016,		Langley, A. and W. Chang, "QUIC Crypto", May 2016,
	<http://goo.gl/OuVSxa>.		<http://goo.gl/OuVSxa>.
	[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>.		<http://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,
	skipping to change at page 36, line 9 ¶		skipping to change at page 40, line 22 ¶
	2014, <http://www.rfc-editor.org/info/rfc7258>.		2014, <http://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,
	<http://www.rfc-editor.org/info/rfc7450>.		<http://www.rfc-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>.		<http://www.rfc-editor.org/info/rfc7541>.
			[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
			Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085,
			March 2017, <http://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
			their helpful review comments.
	Appendix B. Examples		Appendix B. Examples
	This appendix contains examples of multicast QUIC session		This appendix contains examples of multicast QUIC session
	advertisement and resource transfer (with and without application-		advertisement and resource transfer (with and without application-
	layer content security).		layer content security).
	B.1. Session Advertisement		B.1. Session Advertisement
	This section shows several different examples of an HTTP service		This section shows several different examples of an HTTP service
	advertising a multicast QUIC session. Examples are given in IPv4		advertising a multicast QUIC session. Examples are given in IPv4
	skipping to change at page 37, line 4 ¶		skipping to change at page 41, line 24 ¶
	B.1.2. Source-specific Multicast QUIC Session with Transport Encryption		B.1.2. Source-specific Multicast QUIC Session with Transport Encryption
	using a Symmetric Key		using a Symmetric Key
	Advertisement of a multicast QUIC session operating on the IPv6		Advertisement of a multicast QUIC session operating on the IPv6
	globally-scoped source-specific multicast group address ff3e::1234 on		globally-scoped source-specific multicast group address ff3e::1234 on
	port 2000 with the source address 2001:db8::1. The session ID is 16		port 2000 with the source address 2001:db8::1. The session ID is 16
	(0x10) and the idle timeout is one minute. At most 10 resources may		(0x10) and the idle timeout is one minute. At most 10 resources may
	be concurrently active in the session and the flow rate should not		be concurrently active in the session and the flow rate should not
	exceed 10 kbits/s. The multicast transport is encrypted using the		exceed 10 kbits/s. The multicast transport is encrypted using the
	AEAD cipher suite 0x13,0x01 ("TLS_AES_128_GCM_SHA256") and the shared		AEAD cipher suite 0x13,0x01 ("TLS_AES_128_GCM_SHA256") with the
	session key provided.		shared session key and IV provided.
	HTTP Alternative Service header field:		HTTP Alternative Service header field:
	Alt-Svc:		Alt-Svc:
	hqm="[ff3e::1234]:2000"; source-address="2001:db8::1"; quic=1;		hqm="[ff3e::1234]:2000"; source-address="2001:db8::1"; quic=1;
	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		cipher-suite=1301; key=4adf1eab9c2a37fd; iv=4dbe593acb4d1577ad6ba7dc3189834e
			B.1.3. Source-specific Multicast QUIC Session with Transport
			Encryption, Content Integrity and Authenticity
			Advertisement of a multicast QUIC session operating on the IPv6
			globally-scoped source-specific multicast group address ff3e::1234 on
			port 2000 with the source address 2001:db8::1. The session ID is 16
			(0x10) and the idle timeout is one minute. At most 10 resources may
			be concurrently active in the session and the flow rate should not
			exceed 10 kbits/s. The multicast transport is encrypted using the
			AEAD cipher suite 0x13,0x01 ("TLS_AES_128_GCM_SHA256") with the
			shared session key and IV provided. Content integrity is in use with
			the digest algorithm set restricted to SHA-256. Content authenticity
			is in use with the signature algorithm set restricted to rsa-sha256.
			HTTP Alternative Service header field:
			Alt-Svc:
			hqm="[ff3e::1234]:2000"; source-address="2001:db8::1"; quic=1;
			session-id=10; session-idle-timeout=60;
			max-concurrent-resources=10; peak-flow-rate=10000;
			cipher-suite=1301; key=4adf1eab9c2a37fd; iv=4dbe593acb4d1577ad6ba7dc3189834e
			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 "PUSH_PROMISE" or "HEADERS" HTTP/2 frames describe
	the contents of enclosed header block fragments.		the contents of enclosed header block fragments.
	B.2.1. Transfer without Content Integrity or Authenticity		B.2.1. Transfer without Content Integrity or Authenticity
	skipping to change at page 41, line 23 ¶		skipping to change at page 46, line 23 ¶
	signature="MGQCMFTaFptaM2FhgzJq2i9AaChuFDHjp6GiXVtRnI8BsA"		signature="MGQCMFTaFptaM2FhgzJq2i9AaChuFDHjp6GiXVtRnI8BsA"
	Leading "HEADERS" HTTP/2 frame:		Leading "HEADERS" HTTP/2 frame:
	:status: 206		:status: 206
	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=
	QUIC "STREAM" frame containing response body data:		"STREAM" QUIC frame containing response body data:
	...		...
	Trailing "HEADERS" HTTP/2 frame protecting the ":method", ":path",		Trailing "HEADERS" HTTP/2 frame protecting the ":method", ":path",
	":scheme" and ":authority" of the pseudo-request above, plus the		":scheme" and ":authority" of the pseudo-request above, plus the
	"Date", "Digest" and "Content-Range" of the response::		"Date", "Digest" and "Content-Range" of the response:
	content-range: bytes 0-49/100		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
			*RFC Editor's Note:* Please remove this section prior to
			publication of a final version of this document.
			C.1. Since draft-pardue-quic-http-mcast-00
			o Update references to QUIC I-Ds.
			o Relax session leaving requirements language.
			o Clarify handling of omitted session parameter advertisements.
			o Rename "Idle" state to "Quiescent".
			o Add digest algorithm session parameter.
			o Add signature algorithm session parameter.
			o Add Initialization Vector session parameter.
			o Replace COPT tag-value-pairs with TransportParameter values.
			o Add example of an advertisement for a session with content
			authenticity and integrity.
	Authors' Addresses		Authors' Addresses
	Lucas Pardue		Lucas Pardue
	BBC Research & Development		BBC Research & Development
	Email: lucas.pardue@bbc.co.uk		Email: lucas.pardue@bbc.co.uk
	Richard Bradbury		Richard Bradbury
	BBC Research & Development		BBC Research & Development
End of changes. 86 change blocks.
	245 lines changed or deleted		507 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/