Subject: Multicast streaming video client

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 25 Jan 2017 19:49:07 -0500

​One of the big complaints coming back from the inauguration weekend was
that the vast crowds ​were unable to see the podium or even the rebroadcast
sites. Which has me thinking that there is an application protocol need to
be filled here. If everyone at the demonstration connected up over LTE or
WiFi using our existing protocols, the bandwidth would be sucked dry. Same
thing happens in convention spaces (and IETF meetings).

I won't be able to get to work on this till 2018 at the earliest and even
then, I can probably add most value on the crypto side. Some of the results
I have been getting with proxy re-encryption are very promising. We could
get to a genuinely end to end encrypted Web some time.

Now quite possibly, there is something of the sort already built. In fact I
proposed something of the sort several years ago but that specific need was
overtaken by events.

Imagine that there is a video streaming client that takes its content
stream from a combination of a multicast channel and a unicast channel. At
a coarse level, the client receives packets over the multicast link and
requests retransmission over the unicast.

It is going to be a little trickier than that of course because if you have
a stream and one packet drops at the upstream side, the source is going to
get slammed if every client asks for retransmit at once. So there has to be
some research on how to avoid slamming the source. Perhaps there is a
random element in requesting retransmit. Given that we are talking video
here, we can accept latencies of quite a few frames.

It seems to me that the logical starting point for standardizing such a
protocol would be the QUIC RFCs. But as I point out above, this would
require a research effort before standardization.

Just a thought.

---

From: Ross Finlayson <[email-masked]>
Date: Thu, 26 Jan 2017 13:58:47 +1300

> Imagine that there is a video streaming client that takes its content stream from a combination of a multicast channel and a unicast channel. At a coarse level, the client receives packets over the multicast link and requests retransmission over the unicast.

There was some very preliminary work recently presented to the (RTP) “PAYLOAD” working group describing a proposal to optimize a HTTP Adaptive Streaming video infrastructure (i.e., "HTTP Live Streaming" or “DASH”) when a live video event is carried over a multicast network.  The proposal currently has lots of issues to be fleshed out, and (AFAIK) it’s still unclear whether it'll become a working group - but if you’re interested, see the thread here:
	https://mailarchive.ietf.org/arch/search/?email_list=payload&qdr=y&gbt=1&index=N4qSH2GcGVdMwDUNbWEdDCy5bjs

    Ross.

---

From: Ross Finlayson <[email-masked]>
Date: Thu, 26 Jan 2017 14:06:31 +1300

> On Jan 26, 2017, at 1:58 PM, Ross Finlayson <[email-masked]> wrote:
> 
>> The proposal currently has lots of issues to be fleshed out, and (AFAIK) it’s still unclear whether it'll become a working group

Oops, I meant, of course, “working group *item*”.

	Ross.