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.