Re: [V3] Thoughts on scope for ript

Justin Uberti <juberti@google.com> Wed, 25 March 2020 19:50 UTC

Return-Path: <juberti@google.com>
X-Original-To: v3@ietfa.amsl.com
Delivered-To: v3@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 823693A0CBC for <v3@ietfa.amsl.com>; Wed, 25 Mar 2020 12:50:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.599
X-Spam-Level:
X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dSD1tlhAY5jN for <v3@ietfa.amsl.com>; Wed, 25 Mar 2020 12:50:08 -0700 (PDT)
Received: from mail-vk1-xa2c.google.com (mail-vk1-xa2c.google.com [IPv6:2607:f8b0:4864:20::a2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 686EA3A0CD9 for <v3@ietf.org>; Wed, 25 Mar 2020 12:50:08 -0700 (PDT)
Received: by mail-vk1-xa2c.google.com with SMTP id s194so1032329vkb.11 for <v3@ietf.org>; Wed, 25 Mar 2020 12:50:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=PA17Z91vO0s0WjmpOGpa53Tbegd6mQoSHZIEbt2jmKQ=; b=VoR/u0ut6P+ZHzFPLiM3BxfEf6DP6eW2qYtjVf4H46cZ8IOgf2mg8717CZ/ZwcbXu9 6qtSlnCkOFKEClWjEciVilDAOutSAAZKTLqedlmbXeWxJ/L+zzCh1ohchpBLqyMkdsS9 iIairlvH+d/CfzFAJUnHeNNR09WnKXbw3AuYYvxnTMFDS4qM+BSnhNSFqkAGqkHMHtte rIJXndT3zK9uT3pujBwWtp2Zonh5ub/QC4vw6jsS77sBQt17EvuT6w1tu9kez/HMojvM xEo5U7CczpcGmQzGBYzUWtOYNbBoYhpgkr/guCCQfF4yltDpc2iBXJEWzKaoReqRH5E6 4LFQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=PA17Z91vO0s0WjmpOGpa53Tbegd6mQoSHZIEbt2jmKQ=; b=aPPIdiLvs/V/lTZl/E2ctpr8guv7aIPK0e/4uAe1c/ga8ElaGBoNo2GiLs2cuQ5s3y Yr7BkccbzqZkkNn9pj+zwvTM75C+pz/V013Cmqxt3C54jGwMC8Vomvbuoq5Awl7qkl5Q 7ojL2rhhO428sNYSMqccYHTVWp2Rbm4DqRDcO+e5pSM5g1ippAYLghlQi09Lh8bYaegx 7Mhu0fsX/jsf35siMvK3flT5ll8MA+qoEi7JABTcFxstdzANfLJpSsj48zFKQSuqXtJw 2+i4rLAy5azgDhgnTX3yJOzdwDJL5mhDpXrG/uWH7wreWsLvYR3rOytZHBaLk2dNmsi6 72ow==
X-Gm-Message-State: ANhLgQ1oW84k9Rj7gzKjdgp5MDJNQxBkgBTN33Nm371jTwPI7FYWxc3p 6SNaVVljPMzgb7MvnZJCjvNVpVj+Cd90CF2Xx5H2bg==
X-Google-Smtp-Source: ADFU+vv/rPj90aaEpjZ5yH8rQlS3UZHxT1G03TLPei+yl2q0AFm148KSFTzx8TLU6BwsX5OBA4rqCquWbmOWN3ZC8/4=
X-Received: by 2002:a1f:bf95:: with SMTP id p143mr3882455vkf.29.1585165806934; Wed, 25 Mar 2020 12:50:06 -0700 (PDT)
MIME-Version: 1.0
References: <BYAPR06MB4391FBC64E195E87003061B8FBF00@BYAPR06MB4391.namprd06.prod.outlook.com> <CAOJ7v-0MP4p=tpzgNJu1Mxgt8cv4PL01PbQWhTzN6bYSQR9Yuw@mail.gmail.com> <CAAZdMadmEuZz4T6t6BP_=ZMUrducE4g-qwYHpeiB8Ho8SEKCsQ@mail.gmail.com> <CAKKJt-d-6O1_aP1_7KENQSMYyE5yLhrbSCxec1TEEDB_0ss6=Q@mail.gmail.com> <CAOJ7v-0SEtMPedQ=Jga5ErTTTeacUjCKTOZd1arzUDKDVXjyoQ@mail.gmail.com> <CAKKJt-cZ+oxysgsyoGVQyV_z3GALT9uEYcwia5qLONjw1Oc2Rg@mail.gmail.com> <CAOJ7v-230-EskWz0abxcmTEpz4jf7xuVjOeVYeuxbEA3p2pr2Q@mail.gmail.com> <A45D04C3-D640-485D-BAF4-611DBE41DBAA@stewe.org>
In-Reply-To: <A45D04C3-D640-485D-BAF4-611DBE41DBAA@stewe.org>
From: Justin Uberti <juberti@google.com>
Date: Wed, 25 Mar 2020 12:49:55 -0700
Message-ID: <CAOJ7v-25kNE+rg+Jk25YuRVa5RT7JtBZR0jnPh-motsbHFAa9w@mail.gmail.com>
To: Stephan Wenger <stewe@stewe.org>
Cc: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>, Victor Vasiliev <vasilvv@google.com>, Jonathan Rosenberg <jdrosen@five9.com>, "v3@ietf.org" <v3@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000d5ab4605a1b32cf9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v3/SPjZBG5nhWiyHAoSzNmBWU6Hgiw>
Subject: Re: [V3] Thoughts on scope for ript
X-BeenThere: v3@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <v3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v3>, <mailto:v3-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v3/>
List-Post: <mailto:v3@ietf.org>
List-Help: <mailto:v3-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v3>, <mailto:v3-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Mar 2020 19:50:20 -0000

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>om>, Jonathan Rosenberg <
> jdrosen@five9.com>gt;, "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/>
.

>