Main.TransportProtocols History
Hide minor edits - Show changes to output
Added lines 1-33:
!! 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
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
