Subject: [V3] Scoping RIPT - ontop of HTTP

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 11 Apr 2020 09:13:45 -0400

One of the big points of discussion has been whether RIPT runs ontop of H3,
should use a new media transport that runs ontop of QUIC natively, supports
webtransport, etc.

If we go back to the original goal of this protocol - it is to make it easy
to deploy real-time apps ontop of public cloud infrastructure which is
heavily based on HTTP. This is a very pragmatic objective, based on the
realities of what is deployed today, and the anticipated trajectory of
those deployments.

Today when one designs a web API, it doesnt require a particular version of
HTTP. It runs over any version, but will work better ontop of higher
versions, benefitting from whatever additional features have come into
later versions of the protocol (e.g., compression).

As such, I'd like to propose that we narrow the scope of RIPT to follow
this pattern. RIPT should be specified in such a way that it can run on any
version of the HTTP protocol, compatible all the way back to HTTP1. If it
is the case that HTTP3 is being used, its design would facilitate sending
media without HOL blocking.

This would enable us to deploy and use RIPT today and mature the protocol,
while also taking measurements of how well TCP works for media transport.
As I'm sure many of you are aware, real-time media is often sent over TCP
in practice -  tunneled over HTTP for example - in order to deal with with
firewalls, nats and other middleboxes. So let us not pretend like this
would have no value without H3.

What about webtransport? I'm proposing that RIPT doesnt use webtransport
directly but rather waits for it to be made available as an http
extension/enhancement (or whatever it ends up being), and then we can
define a RIPT extension using it.

I'd also suggest that we make the assumption that deployment of RIPT is
being done by an entity (an enterprise or a saas provider) who has
awareness of the environment in which it is being deployed and can thus be
certain that H3 is there if they require it. For example, if this is being
used for voip peering between an enterprise and a telco, the enterprise can
elect to deploy ript only once they've upgraded their IP PBX to support
RIPT and have purchased trunking services that support RIPT.  Since RIPT is
fundamentally one-hop - client to server - we dont need to worry about the
unknowns of downstream elements outside of the sphere of control of this
entity. This is another reason why I believe we should also keep the scope
of the work narrowed to client-to-server media as well.

This stance also addresses the question of media. RTP over QUIC may very
well be a worthy goal to pursue, but it is not this. The fundamental
assumption here is HTTP underneath.

Thx,
Jonathan R.

-- 
Jonathan Rosenberg, Ph.D.
[email-masked]
http://www.jdrosen.net