Re: [V3] Thoughts on scope for ript

[Stephan Wenger <[e-mail]>]

Hi Justin, all:

From: V3 <[e-mail]> on behalf of Justin Uberti <juberti=[e-mail]>
Date: Wednesday, March 25, 2020 at 12:32
To: Spencer Dawkins at IETF <[e-mail]>
Cc: Victor Vasiliev <[e-mail]>, Jonathan Rosenberg <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: [V3] Thoughts on scope for ript



On Wed, Mar 25, 2020 at 12:26 PM Spencer Dawkins at IETF <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>> wrote:


On Wed, Mar 25, 2020 at 9:28 AM Spencer Dawkins at IETF <[e-mail]<mailto:[e-mail]>> wrote:
This is interesting ...

On Wed, Mar 25, 2020 at 10:31 AM Victor Vasiliev <vasilvv=[e-mail]<mailto:[e-mail]>> 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?