Re: [AVTCORE] Mapping RTP onto QUIC

Bernard Aboba <bernard.aboba@gmail.com> Tue, 15 September 2020 17:37 UTC

Return-Path: <bernard.aboba@gmail.com>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBF513A14EF for <avt@ietfa.amsl.com>; Tue, 15 Sep 2020 10:37:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 ZZU78JjaG9iy for <avt@ietfa.amsl.com>; Tue, 15 Sep 2020 10:37:50 -0700 (PDT)
Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::233]) (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 F26703A14EA for <avt@ietf.org>; Tue, 15 Sep 2020 10:37:49 -0700 (PDT)
Received: by mail-lj1-x233.google.com with SMTP id c2so3537914ljj.12 for <avt@ietf.org>; Tue, 15 Sep 2020 10:37:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9CYa+zWX7TXCi7eEwHsuv5img9V3C7nuLlpSSvc8rKk=; b=oT0JwKFxaipx50BthaeuqguOiwUn1vGYOJkKwbEscYrejzB9sUt4qiJEglPasjT2rN ybHb7hW1gJDHXQ1f1QRoE3ZKP5D7YKo7As8OYGx8ZK01QpJmyNZRN9hTqop2B4QETsU1 4M7LtAob8o66Nvi0/uQccuicv65S/khaHOeCE+HxdV2syE45Qc9Y1tnUjjfy+AUF894f MvySRYtxq0ORGApC6cdeONKCEaHGm+hXjgzDqp1GJco9vJVfnO/iT1uPjiWHgmde9vq0 oUezOPnxwh3efYEr+Qrw7l6vA4PAOTVS20CqJdnjs3jE1yHl8h2Kjw5HUL8PqLx3UymR ZADA==
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=9CYa+zWX7TXCi7eEwHsuv5img9V3C7nuLlpSSvc8rKk=; b=sAYkaDbf6aCfkPGUxaQm8aOyK3Gzij6zbpX4SUteI8ilyyIgtK39XyZynWO1U3Imoc fkA2tgpvho8MJDaGzuLQLjq4PK5b1qWF1Nw4PmJAxL19PMc9c/B4LWSkwQHCpa3c6hNh KRkMt++81cZCfVS4uZuO+PFELTkcObrWcNPc+lvRdEhGuoU+GBvJebBqmSIHAYXinGzp Z/2iMyANmdjGyqVgFUoyOQFzFVQb3AiRVb/c65wVhkcubU5FNl8jGvGD5LC1Qh/elTdR iSVY/G4Mr2PKvc2/fnMYqqB/dKs6BHHm3Y3e36SfmzzIPqRhDd0XCEfMFhfZeOErvH6H 5kKw==
X-Gm-Message-State: AOAM531YCDXNFZVfLLObb6f6dbPa7NVpbCU7Kv6N8/5HeVNRNaQba1po KISyfLsskXGZshYxcblVcrVzRuDE6P9e4AzNskA=
X-Google-Smtp-Source: ABdhPJz99Hx4h3Lkc2+e2r5Hm/5aHxPHtHqPgbBbfxUQiyXP/XFHh9tKEM4RYHAaKTRu2+XWHvBvsWZ5sJM+2H9Eu7s=
X-Received: by 2002:a2e:9b15:: with SMTP id u21mr3161040lji.283.1600191467612; Tue, 15 Sep 2020 10:37:47 -0700 (PDT)
MIME-Version: 1.0
References: <CAKKJt-dC9ndv6d=vgGUZ2WLFc__joNjGRWAq98mKLXdr=7oeLg@mail.gmail.com>
In-Reply-To: <CAKKJt-dC9ndv6d=vgGUZ2WLFc__joNjGRWAq98mKLXdr=7oeLg@mail.gmail.com>
From: Bernard Aboba <bernard.aboba@gmail.com>
Date: Tue, 15 Sep 2020 10:37:36 -0700
Message-ID: <CAOW+2dtb2LgtEAYJXyX0N3XkTHWMwqF_cJgpZPMdOSmdBSsknQ@mail.gmail.com>
To: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Cc: IETF AVTCore WG <avt@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000ffefd905af5d9b54"
Archived-At: <https://mailarchive.ietf.org/arch/msg/avt/UDik-K7uygYC2NJV3O5m6Glb2s4>
Subject: Re: [AVTCORE] Mapping RTP onto QUIC
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/avt/>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 15 Sep 2020 17:37:52 -0000

Spencer said:

"As best I can decode from the discussion during the RIPT BOF [3], and
subsequent non-chartering, the RIPT BOF participants didn't support moving
forward,"

[BA] The Automatic SIP trunking and Peering (ASAP) WG was subsequently
chartered:
https://datatracker.ietf.org/wg/asap/about/

but the charter seems to omit the media aspects that were discussed during
the RIPT BOF.

The HTTP/3 datagram draft (
https://tools.ietf.org/html/draft-schinazi-quic-h3-datagram) (which played
a part in some of the scenarios described in the RIPT BOF) isn't currently
a WG work item anywhere, although
https://tools.ietf.org/html/draft-ietf-quic-datagram did get adopted by the
QUIC WG.

"but we didn't really converge in those discussions on whether we should be
looking at HTTP/3 for media, or a more conservative mapping of RTP directly
onto QUIC transport."

[BA]  I would agree that those discussions (and subsequent ones) have not
converged.  There are multiple dimensions to the non-convergence.  One axis
is HTTP/3 transport versus direct QUIC transport.   Another dimension is
how HTTP/3 would be used.  The RIPT BOF suggested a general goal of
enabling media to leverage conventional Web infrastructure; one of the
slides showed an HTTP/3 request (with a byte range!) soliciting a response
of HTTP/3 datagrams.  That is quite different from the model used in
WebTransport (either Http3Transport or QuicTransport).

Yet another dimension is what kind of media would be transported over
HTTP/3. This can include conventional streaming media (e.g. DASH or HLS
over HTTP/3), low-latency streaming media (e.g. SRT over HTTP/3), or
realtime media.

In the W3C WebTransport WG (recently formed, see:
https://w3c.github.io/webtransport-charter/charter.html ) there is now a
work item for use cases. So perhaps some greater understanding will come
out of that.
<https://datatracker.ietf.org/wg/asap/about/>

On Tue, Sep 15, 2020 at 8:42 AM Spencer Dawkins at IETF <
spencerdawkins.ietf@gmail.com> wrote:

> Dear AVTCORE,
>
> As part of the set of ideas included in the IETF 107 RIPT BOF [1] there
> was a proposal [2] to use HTTP/3 for media {"when it is available, falling
> back to media byways when it is not").
>
> As best I can decode from the discussion during the RIPT BOF [3], and
> subsequent non-chartering, the RIPT BOF participants didn't support moving
> forward, but we didn't really converge in those discussions on whether we
> should be looking at HTTP/3 for media, or a more conservative mapping of
> RTP directly onto QUIC transport.
>
> I know there have been proposals for an RTP mapping onto QUIC (most
> notably [4]). Are some people in AVTCORE interested in pursuing that
> alternative, now that QUICv1 is banging around in WGLC?
>
> Best,
>
> Spencer, sending this e-mail to AVTCORE at the suggestion of the ART and
> TSV ADs
>
> [1} https://datatracker.ietf.org/group/ript/meetings/
> [2]
> https://tools.ietf.org/html/draft-rosenbergjennings-dispatch-ript-00#section-8.8
> [3] https://www.ietf.org/proceedings/107/minutes/minutes-107-ript-00
> [4] https://tools.ietf.org/html/draft-rtpfolks-quic-rtp-over-quic-01
> _______________________________________________
> Audio/Video Transport Core Maintenance
> avt@ietf.org
> https://www.ietf.org/mailman/listinfo/avt
>