Re: [V3] Thoughts on scope for ript

On Wed, Mar 25, 2020 at 12:52 PM Justin Uberti <juberti=
40google.com@dmarc.ietf.org> wrote:

>
>
> On Wed, Mar 25, 2020 at 12:38 PM Stephan Wenger <stewe@stewe.org> wrote:
>
>> Hi Justin, all:
>>
>>
>>
>> *From: *V3 <v3-bounces@ietf.org> on behalf of Justin Uberti <juberti=
>> 40google.com@dmarc.ietf.org>
>> *Date: *Wednesday, March 25, 2020 at 12:32
>> *To: *Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
>> *Cc: *Victor Vasiliev <vasilvv@google.com>, Jonathan Rosenberg <
>> jdrosen@five9.com>, "v3@ietf.org" <v3@ietf.org>
>> *Subject: *Re: [V3] Thoughts on scope for ript
>>
>>
>>
>>
>>
>>
>>
>> On Wed, Mar 25, 2020 at 12:26 PM Spencer Dawkins at IETF <
>> spencerdawkins.ietf@gmail.com> wrote:
>>
>> Replying to Justin, after reading Victor's reply - thank you both for
>> replying ...
>>
>>
>>
>> On Wed, Mar 25, 2020 at 11:55 AM Justin Uberti <juberti@google.com>
>> wrote:
>>
>>
>>
>>
>>
>> On Wed, Mar 25, 2020 at 9:28 AM Spencer Dawkins at IETF <
>> spencerdawkins.ietf@gmail.com> wrote:
>>
>> This is interesting ...
>>
>>
>>
>> On Wed, Mar 25, 2020 at 10:31 AM Victor Vasiliev <vasilvv=
>> 40google.com@dmarc.ietf.org> wrote:
>>
>> I would like to second Justin's point here about the value of a
>> client-server RTP streaming by itself (e-f, though in-band c-d are also
>> valuable).  There's a lot of value in the world where I can take an HTTP
>> URL to some endpoint in the cloud and give it to, say, an IoT camera device
>> to use as a realtime media sink, or pass it to an off-the-shelf streaming
>> library to show a realtime media source on screen.
>>
>>
>>
>> I know most of my own concerns about RIPT media have started out with
>> "this won't be as good as RTP for media", but what I've been getting from
>> RIPT discussions is, that may not matter as much as I expected.
>>
>>
>>
>> For a use case like Victor's, great media quality would be great, but
>> good enough media quality may be ... good enough.
>>
>>
>>
>> Am I putting words in the mouths of the proponents?
>>
>>
>>
>> Some applications may tolerate somewhat lower quality in fallback
>> scenarios, but I think we should be aiming for RTP performance with HTTP
>> ease of deployment.
>>
>>
>>
>> I was actually hoping that wasn't the case, because ISTM that the
>> question whether RTP performance over HTTP is possible/likely is going to
>> suck up a LOT of the discussion time during the BOF ...
>>
>>
>>
>> To Eric's point, "H3 is not widely deployed yet, and so we should think
>> about how we want things to look". I think it's entirely possible to
>> achieve RTP performance over H3, and hopefully also have a reasonable
>> fallback when only H2 is available.
>>
>>
>>
>> [Stephan]: many video conferencing technologies (including Vidyo, Zoom),
>> have previously, or are currently supporting http-based media transport,
>> often for years or even decades.  They are almost never enabled by any
>> professional deployer, because the resulting QoS is user-perceived as so
>> bad that the marketing guys decided that offering no video/voice (and
>> instead make people pick of the phone) is better for product reputation
>> than offer the degraded QoS.
>>
>> Do any of you guys have hard numbers what sort of delay h3-based
>> transport can achieve on today’s infrastructure?
>>
>
> With H3 we have lots of options; there are lots of details to work through
> here but given that the substrate is QUIC there is no theoretical reason
> why RTP performance isn't possible.
>
> Regarding HTTP media transport in existing products (i.e., non-H3), you
> are correct that there are indeed limitations and as such providers do what
> they can to avoid this option, but it is nowhere near as grim as you make
> it out to be. Recall that the first web version of Zoom exclusively used
> websockets for transport
> <https://webrtchacks.com/zoom-avoids-using-webrtc/>.
>

I mostly concur with Justin here: I would expect QUIC (which is to say
probably H3 + Datagram) to be roughly comparable to RTP [0]. Anything over
TCP will obviously be non-awesome, but we already do have some nontrivial
fraction of media going over TCP to TURN relays, so it's not like it
doesn't work at all, especially in good network conditions.

-Ekr

[0] There are some open issues with how QUIC congestion control and the
media rate control interact, but I imagine they are mostly soluble.

> --
> V3 mailing list
> V3@ietf.org
> https://www.ietf.org/mailman/listinfo/v3
>