< draft-ietf-bier-multicast-http-response-03.txt		draft-ietf-bier-multicast-http-response-04.txt >
	Network Working Group D. Trossen		Network Working Group D. Trossen
	Internet-Draft Huawei		Internet-Draft Huawei
	Intended status: Informational A. Rahman		Intended status: Informational A. Rahman
	Expires: August 7, 2020 C. Wang		Expires: January 11, 2021 C. Wang
	InterDigital Communications, LLC		InterDigital Communications, LLC
	T. Eckert		T. Eckert
	Futurewei		Futurewei
	February 4, 2020		July 10, 2020
	Applicability of BIER Multicast Overlay for Adaptive Streaming Services		Applicability of BIER Multicast Overlay for Adaptive Streaming Services
	draft-ietf-bier-multicast-http-response-03		draft-ietf-bier-multicast-http-response-04
	Abstract		Abstract
	HTTP Level multicast, using BIER, is described as a use case in the		HTTP Level Multicast, using BIER, is described as a use case in the
	BIER Use Cases document. HTTP Level Multicast is used in today's		BIER Use Cases document. HTTP Level Multicast is used in today's
	video streaming and delivery services such as HLS, AR/VR etc.,		video streaming and delivery services such as HLS, AR/VR etc.,
	generally realized over IP Multicast as well as other use cases such		generally realized over IP Multicast as well as other use cases such
	as software update delivery. A realization of "HTTP Multicast" over		as software update delivery. A realization of "HTTP Multicast" over
	"IP Multicast" is described for the video delivery use case. IP		"IP Multicast" is described for the video delivery use case. IP
	multicast is commonly used for IPTV services. DVB and BBF is also		Multicast is commonly used for IPTV services. DVB and BBF also
	developing a reference architecture for IP Multicast service. A few		developes a reference architecture for IP Multicast service. A few
	problems with IP Multicast, such as waste of transmission bandwidth,		problems with IP Multicast, such as waste of transmission bandwidth,
	increase in signaling when there are few users are described.		increase in signaling when there are few users are described.
	Realization over BIER, through a BIER Multicast Overlay Layer, is		Realization over BIER, through a BIER Multicast Overlay Layer, is
	described as an alternative. How BIER Multicast Overlay operation		described as an alternative. How BIER Multicast Overlay operation
	improves over IP Multicast, such as reduction in signaling, dynamic		improves over IP Multicast, such as reduction in signaling, dynamic
	creation of multicast groups to reduce signaling and bandwidth		creation of multicast groups to reduce signaling and bandwidth
	wastage is described. We conclude with few next steps.		wastage is described. We conclude with a few next steps.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on August 7, 2020.		This Internet-Draft will expire on January 11, 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 IETF Trust and the persons identified as the		Copyright (c) 2020 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 6, line 12 ¶		skipping to change at page 6, line 12 ¶
	extended with multicast delivery for HTTP responses in certain use		extended with multicast delivery for HTTP responses in certain use
	cases.		cases.
	3.1. HTTP-based Steaming		3.1. HTTP-based Steaming
	Referring to the BIER Use Cases [I-D.ietf-bier-use-cases], multicast		Referring to the BIER Use Cases [I-D.ietf-bier-use-cases], multicast
	is used to scale out HTTP Live Streaming (HLS) to a large number of		is used to scale out HTTP Live Streaming (HLS) to a large number of
	receivers that use HTTP. This is used today in solutions like DOCSIS		receivers that use HTTP. This is used today in solutions like DOCSIS
	hybrid streaming [TR_IPMC_ABR]. Multicast can speed up both live and		hybrid streaming [TR_IPMC_ABR]. Multicast can speed up both live and
	high-demand VoD streaming. Adaptive Bit Rate IPMC [TR_IPMC_ABR]		high-demand VoD streaming. Adaptive Bit Rate IPMC [TR_IPMC_ABR]
	describes use of IP multicast towards the CMTS or a box beside it,		describes use of IP Multicast towards the CMTS or a box beside it,
	where the content is converted to HTTP/TCP to stream to the receivers		where the content is converted to HTTP/TCP to stream to the receivers
	(e.g., homes). A server hosting the HLS content is shown as "NAP		(e.g., homes). A server hosting the HLS content is shown as "NAP
	Server". The gateways acting as receivers for the multicast from the		Server". The gateways acting as receivers for the multicast from the
	server are shown as "Client-NAP" (CNAP). Each CNAP can serve		server are shown as "Client-NAP" (CNAP). Each CNAP can serve
	multiple clients.		multiple clients.
	Dynamic Adaptive Streaming (DASH) [ISO_DASH] over HTTP is another		Dynamic Adaptive Streaming (DASH) [ISO_DASH] over HTTP is another
	HTTP-based streaming approach. In DASH, each media is described by a		HTTP-based streaming approach. In DASH, each media is described by a
	Media Presentation Description (MPD) file, through which a DASH		Media Presentation Description (MPD) file, through which a DASH
	client (e.g. a media player) is instructed how to download, interpret		client (e.g. a media player) is instructed how to download, interpret
	skipping to change at page 8, line 8 ¶		skipping to change at page 8, line 8 ¶
	o MUST provide direct path mobility, where the path between the		o MUST provide direct path mobility, where the path between the
	egress and ingress Service Routers(SR) can be determined as being		egress and ingress Service Routers(SR) can be determined as being
	optimal (e.g., shortest path or direct path to a selected		optimal (e.g., shortest path or direct path to a selected
	instance), is needed to avoid the use of anchor points and further		instance), is needed to avoid the use of anchor points and further
	reduce service-level latency.		reduce service-level latency.
	5. Realization over IP Multicast		5. Realization over IP Multicast
	We now discuss the realization of chunk-based delivery over IP		We now discuss the realization of chunk-based delivery over IP
	multicast delivery methods. We focus our presentation here on the		Multicast delivery methods. We focus our presentation here on the
	video streaming use case in Section 3.1.		video streaming use case in Section 3.1.
	IPTV or Internet video distribution in CDNs, uses HTTP Level		IPTV or Internet video distribution in CDNs, uses HTTP Level
	Multicast and realized over IP Multicast (IPMC). Many features of		Multicast and realized over IP Multicast (IPMC). Many features of
	the IPTV service uses IPMC Group dependent state. Besides popular		the IPTV service uses IPMC Group dependent state. Besides popular
	features like PIM, Mldp, in a variable bit rate encoded content		features like PIM, Mldp, in a variable bit rate encoded content
	source, content consumption also depends on group state.		source, content consumption also depends on group state.
	DVB released reference architecture [DVB_REF_ARCH] for an end-to-end		DVB released reference architecture [DVB_REF_ARCH] for an end-to-end
	system to deliver linear content over IP networks in a scalable and		system to deliver linear content over IP networks in a scalable and
	standards-compliant manner. It focuses on delivering Adaptive Bit		standards-compliant manner. It focuses on delivering Adaptive Bit
	Rate unicast content over a IP multicast network.		Rate unicast content over a IP Multicast network.
	A Multicast gateway is deployed in a CPE, Upstream Network Edge		A Multicast gateway is deployed in a CPE, Upstream Network Edge
	device or Terminal and provides multicast to unicast conversion		device or Terminal and provides multicast to unicast conversion
	facilities for several homes. All in-scope traffic on the access		facilities for several homes. All in-scope traffic on the access
	network between the Multicast Gateway (e.g. network edge device) and		network between the Multicast Gateway (e.g. network edge device) and
	the Terminal or home gateway device is unicast. The individual media		the Terminal or home gateway device is unicast. The individual media
	files are encapsulated into other protocols, so that they can be		files are encapsulated into other protocols, so that they can be
	recovered as discrete files, when they exit the multicast pipe, which		recovered as discrete files, when they exit the multicast pipe, which
	is terminated at Multicast Gateway. Interface "L" between Multicast		is terminated at Multicast Gateway. Interface "L" between Multicast
	server and Content playback supports fetching of all specified types		server and Content playback supports fetching of all specified types
	skipping to change at page 8, line 42 ¶		skipping to change at page 8, line 42 ¶
	also started similar work in October 2016, called WT-399. This work		also started similar work in October 2016, called WT-399. This work
	is now coordinated with DVB. BBF focuses on developing the device		is now coordinated with DVB. BBF focuses on developing the device
	management model.		management model.
	Assume clients that are consuming the same content (such as a TV		Assume clients that are consuming the same content (such as a TV
	program) and that this content has for each block (typically segments		program) and that this content has for each block (typically segments
	worth 2 seconds of content) a set of outstanding requests from its		worth 2 seconds of content) a set of outstanding requests from its
	clients. When IP Multicast is used in the domain, such as in		clients. When IP Multicast is used in the domain, such as in
	aforementioned pre-existing solutions like in Cablelabs/DOCSIS		aforementioned pre-existing solutions like in Cablelabs/DOCSIS
	[TR_IPMC_ABR], all possible blocks of the content have to be mapped		[TR_IPMC_ABR], all possible blocks of the content have to be mapped
	to some IP multicast group, and the CNAP will need to know the		to some IP Multicast group, and the CNAP will need to know the
	mapping of block to groups. For example, a live stream may have 11		mapping of block to groups. For example, a live stream may have 11
	different bitrates available. In the most simple Block to IP		different bitrates available. In the most simple Block to IP
	multicast group mapping scheme, there could be 11 multicast groups,		Multicast group mapping scheme, there could be 11 multicast groups,
	one for all the blocks of one bitrate (note that this is not		one for all the blocks of one bitrate (note that this is not
	necessarily done in deployments of this solution, but we consider it		necessarily done in deployments of this solution, but we consider it
	here for the purpose of explanation).		here for the purpose of explanation).
	If the multicast domain and especially the links into the CNAP has		If the multicast domain and especially the links into the CNAP has
	enough bandwidth, this solution work well with IP multicast. As soon		enough bandwidth, this solution work well with IP Multicast. As soon
	as there is at least one Client connected to a CNAP for one		as there is at least one Client connected to a CNAP for one
	particular content, the CNAP would join all 11 multicast groups for		particular content, the CNAP would join all 11 multicast groups for
	this content.		this content.
	5.1. Mapping to Requirements		5.1. Mapping to Requirements
	To realize "HTTP Level Multicast" over "IP Multicast", some		To realize "HTTP Level Multicast" over "IP Multicast", some
	additional functions needs to be supported in an intermediate		additional functions needs to be supported in an intermediate
	(overlay) layer.		(overlay) layer.
	skipping to change at page 9, line 31 ¶		skipping to change at page 9, line 31 ¶
	Support of IGMP signaling between User device, NAPs and Multicast		Support of IGMP signaling between User device, NAPs and Multicast
	Router.		Router.
	5.2. Problems		5.2. Problems
	If the number of clients on a CNAP for a particular program is large,		If the number of clients on a CNAP for a particular program is large,
	the approach will work fairly well, because the likelihood that each		the approach will work fairly well, because the likelihood that each
	of the 11 bitrates of a content is necessary for at least one Client		of the 11 bitrates of a content is necessary for at least one Client
	is then fairly high.		is then fairly high.
	When the number of receivers is not very large, IP multicast runs		When the number of receivers is not very large, IP Multicast runs
	into two issues. If all the bitrates for the content are sent across		into two issues. If all the bitrates for the content are sent across
	the same group, then many of the bitrates may not be required and		the same group, then many of the bitrates may not be required and
	would have to be received unnecessarily and dropped by the CNAP. If		would have to be received unnecessarily and dropped by the CNAP. If
	each bitrate was sent on a different IP multicast group, the CNAP		each bitrate was sent on a different IP Multicast group, the CNAP
	could dynamically join/leave each multicast group based on the known		could dynamically join/leave each multicast group based on the known
	receivers, but that would create an extremely high and undesirable		receivers, but that would create an extremely high and undesirable
	amount of IP multicast signaling protocol activity (PIM/IGMP) that is		amount of IP Multicast signaling protocol activity (PIM/IGMP) that is
	easily overloading the network		easily overloading the network
	For efficiency reasons, the CNAP would need to dynamically join to		For efficiency reasons, the CNAP would need to dynamically join to
	only those bitrate steams where it does have outstanding requests,		only those bitrate steams where it does have outstanding requests,
	therefore achieving the best efficiency. This would mean in the		therefore achieving the best efficiency. This would mean in the
	worst case that a CNAP would need to send for each new block, aka.:		worst case that a CNAP would need to send for each new block, aka.:
	every two second for every client one IGMP/PIM leave and one IGMP/PIM		every two second for every client one IGMP/PIM leave and one IGMP/PIM
	join towards the upstream router to get a block for an appropriate		join towards the upstream router to get a block for an appropriate
	bitrate (or changed content) whenever bitrate or content on a client		bitrate (or changed content) whenever bitrate or content on a client
	have changed. This high rate of control-plane signaling between CNAP		have changed. This high rate of control-plane signaling between CNAP
	skipping to change at page 13, line 42 ¶		skipping to change at page 13, line 42 ¶
	Upon arrival of an HTTP response at the server SH, the server SH		Upon arrival of an HTTP response at the server SH, the server SH
	consults its internal request table for any outstanding HTTP requests		consults its internal request table for any outstanding HTTP requests
	to the same request. The server SH retrieves the stored BIER		to the same request. The server SH retrieves the stored BIER
	forwarding information for the reverse direction for all outstanding		forwarding information for the reverse direction for all outstanding
	HTTP requests and determines the path information to all client SHs		HTTP requests and determines the path information to all client SHs
	through a binary OR over all BIER forwarding identifiers with the		through a binary OR over all BIER forwarding identifiers with the
	same SI field. This newly formed joint BIER multicast response		same SI field. This newly formed joint BIER multicast response
	identifier is used to send the HTTP response across the network.		identifier is used to send the HTTP response across the network.
	BIER makes the solution scalable. Instead of IP multicast with IGMP/		BIER makes the solution scalable. Instead of IP Multicast with IGMP/
	PIM, BIER is being used between Server NAP (SNAP) and CNAP, the SNAP		PIM, BIER is being used between Server NAP (SNAP) and CNAP, the SNAP
	simply coalesces the forwarded HTTP requests from the CNAP, and		simply coalesces the forwarded HTTP requests from the CNAP, and
	determines for every requested block the set of CNAPs requesting it.		determines for every requested block the set of CNAPs requesting it.
	A set of CNAPs corresponds to a set of bits in the BIER-bitstring,		A set of CNAPs corresponds to a set of bits in the BIER-bitstring,
	one bit per CNAP. The SNAP then sends the block into BIER with the		one bit per CNAP. The SNAP then sends the block into BIER with the
	appropriate bitstring set.		appropriate bitstring set.
	This completely eliminates any dynamic multicast signaling between		This completely eliminates any dynamic multicast signaling between
	CNAP and SNAP. It also avoids sending of any unnecessary data block,		CNAP and SNAP. It also avoids sending of any unnecessary data block,
	which in the IP multicast solution is pretty much unavoidable.		which in the IP Multicast solution is pretty much unavoidable.
	Furthermore, using the approach with BIER, the SNAP can also easily		Furthermore, using the approach with BIER, the SNAP can also easily
	control how long to delay sending of blocks. For example, it may		control how long to delay sending of blocks. For example, it may
	wait for some percentage of the time of a block (e.g, 50% = 1		wait for some percentage of the time of a block (e.g, 50% = 1
	second), therefore ensuring that it is coalescing as many requests		second), therefore ensuring that it is coalescing as many requests
	into one BIER multicast answer as possible.		into one BIER multicast answer as possible.
	6.3. BIER Multicast Overlay Traffic Management		6.3. BIER Multicast Overlay Traffic Management
	BIER-TE (BIER Traffic Engineering [I-D.ietf-bier-te-arch]) forwards		BIER-TE (BIER Traffic Engineering [I-D.ietf-bier-te-arch]) forwards
	skipping to change at page 15, line 15 ¶		skipping to change at page 15, line 15 ¶
	extraction of the suitable request parameters while allowing for the		extraction of the suitable request parameters while allowing for the
	re-encryption of the content for an encrypted delivery over the BIER		re-encryption of the content for an encrypted delivery over the BIER
	network. Since we liken the relationship between content and BIER		network. Since we liken the relationship between content and BIER
	overlay provider to that between content and CDN provider, the		overlay provider to that between content and CDN provider, the
	existence of certificate sharing agreements is similar to the		existence of certificate sharing agreements is similar to the
	practice used for CDNs.		practice used for CDNs.
	9. Informative References		9. Informative References
	[DVB_REF_ARCH]		[DVB_REF_ARCH]
	DVB, "Adaptive media streaming over IP multicast", DVB		DVB, "Adaptive media streaming over IP Multicast", DVB
	Document A176, March 2018,		Document A176, March 2018,
	<https://www.dvb.org/resources/public/standards/a176_adapt		<https://www.dvb.org/resources/public/standards/a176_adapt
	ive_media_streaming_over_ip_multicast_2018-02-16_draft_blu		ive_media_streaming_over_ip_multicast_2018-02-16_draft_blu
	ebook.pdf>.		ebook.pdf>.
	[I-D.ietf-bier-te-arch]		[I-D.ietf-bier-te-arch]
	Eckert, T., Cauchie, G., Braun, W., and M. Menth, "Traffic		Eckert, T., Cauchie, G., Braun, W., and M. Menth, "Traffic
	Engineering for Bit Index Explicit Replication (BIER-TE)",		Engineering for Bit Index Explicit Replication (BIER-TE)",
	draft-ietf-bier-te-arch-00 (work in progress), January		draft-ietf-bier-te-arch-00 (work in progress), January
	2018.		2018.
	[I-D.ietf-bier-use-cases]		[I-D.ietf-bier-use-cases]
	Kumar, N., Asati, R., Chen, M., Xu, X., Dolganow, A.,		Nainar, N., Asati, R., Chen, M., Xu, X., Dolganow, A.,
	Przygienda, T., Gulko, A., Robinson, D., Arya, V., and C.		Przygienda, T., Gulko, A., Robinson, D., Arya, V., and C.
	Bestler, "BIER Use Cases", draft-ietf-bier-use-cases-10		Bestler, "BIER Use Cases", draft-ietf-bier-use-cases-11
	(work in progress), August 2019.		(work in progress), March 2020.
	[I-D.ietf-httpbis-bcp56bis]		[I-D.ietf-httpbis-bcp56bis]
	Nottingham, M., "On the use of HTTP as a Substrate",		Nottingham, M., "On the use of HTTP as a Substrate",
	draft-ietf-httpbis-bcp56bis-05 (work in progress), May		draft-ietf-httpbis-bcp56bis-05 (work in progress), May
	2018.		2018.
	[I-D.irtf-icnrg-deployment-guidelines]		[I-D.irtf-icnrg-deployment-guidelines]
	Rahman, A., Trossen, D., Kutscher, D., and R. Ravindran,		Rahman, A., Trossen, D., Kutscher, D., and R. Ravindran,
	"Deployment Considerations for Information-Centric		"Deployment Considerations for Information-Centric
	Networking (ICN)", draft-irtf-icnrg-deployment-		Networking (ICN)", draft-irtf-icnrg-deployment-
End of changes. 21 change blocks.
	23 lines changed or deleted		23 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/