Re: [V3] Thoughts on scope for ript

[Justin Uberti <[e-mail]>]

On Wed, Mar 25, 2020 at 12:26 PM Spencer Dawkins at IETF <
[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]> wrote:
>
>>
>>
>> On Wed, Mar 25, 2020 at 9:28 AM Spencer Dawkins at IETF <
>> [e-mail]> wrote:
>>
>>> This is interesting ...
>>>
>>> On Wed, Mar 25, 2020 at 10:31 AM Victor Vasiliev <vasilvv=
>>> [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.