Transport Protocols for Media

Steve: HTTP sucks for Media

• slow-start penalty
• no way to abort connections without tearing down a session
• has anyone experimented with other methods of streaming?
• websockets?
• quick (developed by google) using spdy and others; built off of udp; can restart with any server it connected to earlier; multiplexed; no multiple head-of-line blocking
• http2 is build off of spdy4, https inherits TLS authorization and is slow; not useful for video

Question for discussion: not which protocol is best, but: what do people in the room want from media protocols? What can we realistically add? For media/live streaming (but not WebRTC) how can we evolve the JS surfaces? What are suggestions/feedback?

Lorenzo: what about firewalls?

Steve: http-like protocol has the firewall advantage, so we need to consider how to fall back to HTTP

Lorenzo: we're doing srtp, which is being used for WebRTC; uses congestion control, udp, firewall punching etc; rtp is just a transport mechanism for frames - signalling is separate; might be worth investigating for media delivery, too

Steve: does that mean to incorporate a lot of logic into the server?

Lorenzo: there are things you can originate from the client side; e.g. simulcast is being worked on in IETF; there are companies that believe it's a viable mechanism for such a problem

Steve: there have been initiatives for H.264 for redundancy; deep level of integration between media codec and munging; even transmitting offset of such information bears a huge penalty; redundant coding layers in VP9?; network layers repeat functionality of transport protocols

Discussion between diverse aims of multicast, adaptive streaming, scalable coding

Steve: request prioritization at YouTube? are request deadlines; special YouTube? use case - doesn't seem like it's a general use case

Ami: some parts of communications have higher prio; e.g. chat, which is shorter

Take-away:

• look at RTP and see what you may be able to learn from it
• check out quick