I thought I'd capture here some iffy text that I wasn't happy enough with to include yet, but might be worth finishing to fill in the "Pool/ Channel management on the server side" part from https://github.com/GrumpyOldTroll/draft-jholland-quic-multicast/issues/61 that I skipped when closing that issue.
The goal really is to make it clear what kinds of channel assignment strategies you'd want for a few different use cases, which I don't think this text quite achieves.
I'm not sure it's worth it, it seems like a lot of background in order to cover some non-normative example stuff that might be better done by an example implementation outside the spec, but I thought I'd leave this here for a bit more discussion instead of just dropping the "pool/Channel management" suggestion.
Maybe it would be better with a slightly different direction I just haven't thought of properly, I'm not sure. But this is what my interpretation started out typing, until it kinda felt like maybe more of a can of worms than it's worth, so I thought I'd dump it in here for possibly a later rev.
Please do suggest direction or text here if you think there's something worth filling out and incorporating, but I'm kind of inclined to drop it at the moment.
Application Use Cases {#application-use-cases}
This section covers some potentially useful applications and some of their deployment considerations if using multicast QUIC for the data delivery.
Live Adaptive Bitrate Media
Adaptive bitrate media (for example using HLS {{RFC8216}} or DASH {{MPEG-DASH}}) that's either live or has high concurrency among end users (for example right after release of a new episode of a popular show) can benefit from leveraging multicast delivery because many end users are trying to consume the same data at roughly the same time.
However, adaptive bitrate systems deliver different media segments to different end users according to the bitrate their network connections can support under the changing network conditions detected by the client.
Useful techniques:
send each segment in a separate stream, so that there's no dependency on prior content in a stream that might not have been delivered to a client that switched bitrates
deliver the most popular or highest bitrate content over multicast, and deliver lower bitrates or bitrates with fewer consumers over unicast.
Pre-loading Popular Video Clips
Video clips that will predictably be delivered to many users can usefully be delivered and cached with multicast QUIC, then served from cache when appropriate.
For example, advertisements for a cohort of end users or "trending" video clips for social media applications that have a wide audience might be delivered on a multicast channel that the server asks clients to join according to group memberships they have within the social media application. Then as users scroll their media feed, the advertisements or the popular video clips that are already pre-positioned can be inserted in the feed where appropriate without new network traffic (playing the content from a local cache), even though the users' consumption of these clips may not be synchronized.
File Transfer
Existing unidirectional file transfer protocols based on ALC {{RFC5775}} and FEC {{RFC6363}} can leverage multicast to send the same file to many end users even though they might start at different times and consume the data at different rates.
GrumpyOldTroll
commented
2 years ago
I thought I'd capture here some iffy text that I wasn't happy enough with to include yet, but might be worth finishing to fill in the "Pool/ Channel management on the server side" part from https://github.com/GrumpyOldTroll/draft-jholland-quic-multicast/issues/61 that I skipped when closing that issue.
The goal really is to make it clear what kinds of channel assignment strategies you'd want for a few different use cases, which I don't think this text quite achieves.
I'm not sure it's worth it, it seems like a lot of background in order to cover some non-normative example stuff that might be better done by an example implementation outside the spec, but I thought I'd leave this here for a bit more discussion instead of just dropping the "pool/Channel management" suggestion.
Maybe it would be better with a slightly different direction I just haven't thought of properly, I'm not sure. But this is what my interpretation started out typing, until it kinda felt like maybe more of a can of worms than it's worth, so I thought I'd dump it in here for possibly a later rev.
Please do suggest direction or text here if you think there's something worth filling out and incorporating, but I'm kind of inclined to drop it at the moment.
Application Use Cases {#application-use-cases}
This section covers some potentially useful applications and some of their deployment considerations if using multicast QUIC for the data delivery.
Live Adaptive Bitrate Media
Adaptive bitrate media (for example using HLS {{RFC8216}} or DASH {{MPEG-DASH}}) that's either live or has high concurrency among end users (for example right after release of a new episode of a popular show) can benefit from leveraging multicast delivery because many end users are trying to consume the same data at roughly the same time.
However, adaptive bitrate systems deliver different media segments to different end users according to the bitrate their network connections can support under the changing network conditions detected by the client.
Useful techniques:
Pre-loading Popular Video Clips
Video clips that will predictably be delivered to many users can usefully be delivered and cached with multicast QUIC, then served from cache when appropriate.
For example, advertisements for a cohort of end users or "trending" video clips for social media applications that have a wide audience might be delivered on a multicast channel that the server asks clients to join according to group memberships they have within the social media application. Then as users scroll their media feed, the advertisements or the popular video clips that are already pre-positioned can be inserted in the feed where appropriate without new network traffic (playing the content from a local cache), even though the users' consumption of these clips may not be synchronized.
File Transfer
Existing unidirectional file transfer protocols based on ALC {{RFC5775}} and FEC {{RFC6363}} can leverage multicast to send the same file to many end users even though they might start at different times and consume the data at different rates.