Multicast streaming video client

[Phillip Hallam-Baker <[e-mail]>]

​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.