Subject: Re: [rtcweb] RTP multiplexing - my understanding of status

From: Michael Thornburgh <[email-masked]>
Date: Tue, 14 Jun 2011 18:08:24 -0700

(apologies for breaking the "in-reply-to" threadiness; i've been reading the list through the archive web page)

On 6/13/2011 11:49:34 -0400, Randell Jesup wrote:
> I assume the Matthew Kaufman here is the same one who presented the paper on RTMFP for Adobe at IETF 77. :-) From the email address, I take it you work for Skype now.

> While that protocol per se may be out-of-bounds (proprietary, patents), some of the problems they were trying to solve aren't entirely different than what we're looking at here.

except for "interoperation with legacy systems" and "no plug-ins", the problems we set out to solve with RTMFP were almost exactly the same: secure, real-time, congestion controlled, safe P2P communication of voice, video, and data in the browser, with NAT traversal.

> In particular, there may be advantages in setup time and complexity to reducing the number of "5-tuples" required and multiplexing data. For example, if you need to poke holes in a firewall using UPnP it can be painful and slow (to the point where we at WorldGate pre-poked holes to use if a call came in, and we had to keep 2 or 3 sets of holes open to handle call-waiting cases, etc). Even ignoring that and just considering ICE, the number of messages to open N ports is a lot higher than 1 or a pair of ports, and it may also increase the chance of a single-packet loss interfering and slowing down convergence (or pushing ICE to select a sub-optimal connection method). Also, what are the odds of ICE selecting different methods for the different streams?

RTMFP takes multiplexing over UDP further: communications with multiple distinct endpoints can (if desired) share the same UDP port on a host, which can make more efficient use of NAT resources and traversal-helpers (the "Redirectors" and "Forwarders" from Matthew's presentation at IETF 77 [1, pp19-30]).

> As mentioned, if this is done as a shim/multiplex layer it simplifies interop with existing voice gateways. Side note: there is a draft for (just) multiplexing RTP and RTCP which I had weighed in on and supported; I forget where it stands currently.

> Another goal from RTMFP that is worth considering is consolidated congestion control - doing congestion control and bandwidth measurement/adaptation across all the streams exchanged with another endpoint together. This is simplified by using a single or smaller number of "5-tuples", though it isn't gated on that.

> Thought should be given to some of the other goals of RTMFP and if they're in-scope or not. (IP addr changes, etc).

some other goals of RTMFP to which thought should be given:
  * all traffic is congestion controlled all the time (i know RTCWeb is already thinking about this, but we think it's critical so i'm mentioning it again)
     * consolidated congestion control for prioritization of traffic (for example, control/signaling over media, audio over video & data, real-time data over bulk data)
     * multi-endpoint cooperative congestion control for real-time vs not-real-time concurrent communications [1, p34]
  * full or partial reliability for data (and audio & video media)
  * ordered or un-ordered (ASAP) receipt of messages
  * fragmentation/reassembly of large (>504 bytes) data messages
  * flow association to provide unambiguous channel grouping of distinct parallel communications between a single pair of endpoints, still sharing a single security association, UDP port, congestion control and prioritization domain
  * perform endpoint "white listing" based on ephemeral cryptographic identity instead of IP address/port number, while still using end-to-end encryption keying

Michael Thornburgh

[1] http://www.ietf.org/proceedings/10mar/slides/tsvarea-1.pdf