Re: [AVTCORE] Mapping RTP onto QUIC

Bernard Aboba <> Thu, 17 September 2020 14:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9381D3A011B for <>; Thu, 17 Sep 2020 07:32:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id gJ-6WmgrMw6t for <>; Thu, 17 Sep 2020 07:32:54 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 112C93A0964 for <>; Thu, 17 Sep 2020 07:32:53 -0700 (PDT)
Received: by with SMTP id a22so2197182ljp.13 for <>; Thu, 17 Sep 2020 07:32:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=n9VSpvs9ETIvhoKLbjRbY0q63mOpRz6MC3CBl3yeRAY=; b=odxCsPiaezfRrJtl3Hjp3m4rAR0DFUgY3VYFARLkc2oygU3TX9kDl7gF1b5kCMttGZ 7Amah4eW/KGgiEkiXe7ENzeQfh3NZnWktpDVROvKaXrr/JXFEtvpK/vUA/EieZINinkr Nqr/FTFpxcYQIswrxdle+mo3UJJZN4uzo12K6KxA1upRTnP5+42NDQCy+UQdEZ5FGZVn CvhsJiYEcPqQcPiypDAKAuazPnUkCkLMu6FggA3Vq1eB9MwscW1EPsV7GUML2ZEyR9vt FQwzRVaLG5xnZDdtRPtFEP8ystsS4+5zoCwVDpWkR+0Kz/XPpbl31+OtjfhSPng1vX5Z wJhA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=n9VSpvs9ETIvhoKLbjRbY0q63mOpRz6MC3CBl3yeRAY=; b=ekmsMNgYWGqbJjb4zoB+4BfOrpnTlx9rrW0cYoEBj5/udMMUjTpdU/boQOr+QxyoP7 SRGIkXdmG0r9ScPJTIFO9zZZjl+w4FWwF81eHv470SYooSQIRtN2gAezfhkhvEDisgJw WktGP0pYGs5+6QNkkOV1qQrQPZignD2n4jcFOLylKtrjNVWgruE8hnz9xrXXSgQkxhvG NENL7aVHGCImtYMmAUb2P4B5AoCEOuPLpRT/h/5qTD/ikU5Q0L8YNuyf7HP387UoCgMN OWFisH7IqOq0B7NRrabVRmt882wPNkkxiJBVBYbVeqAsrd/7Gmozhwrxx+1tTll1DcaV Z0Jw==
X-Gm-Message-State: AOAM533DMe827eDMZi5QdOMplLNN/oOZCaoNeMD9qVe1WXROx72M6dGE 1pA+vwjMKBY8+SZc3YjXW+nHzSMPxesIUC3Fhcc=
X-Google-Smtp-Source: ABdhPJw/jKbq/G+fjF7u8VWyha5fCEnQWp/6ggbsOpzCvwTHlDbFc7NFRXqQAbLii3RbnQi0AxB9XgTHI8YOSnTBhaI=
X-Received: by 2002:a2e:3507:: with SMTP id z7mr9383724ljz.317.1600353171872; Thu, 17 Sep 2020 07:32:51 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Bernard Aboba <>
Date: Thu, 17 Sep 2020 07:32:41 -0700
Message-ID: <>
To: Spencer Dawkins at IETF <>
Cc: IETF AVTCore WG <>
Content-Type: multipart/alternative; boundary="000000000000531f4905af8342cd"
Archived-At: <>
Subject: Re: [AVTCORE] Mapping RTP onto QUIC
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 17 Sep 2020 14:32:57 -0000

Spencer said:

"I'd like to talk to anyone else who is also experimenting (and can talk
about it)."

[BA] Experimentation has only become possible very recently, with the
Origin Trials of QuicTransport and WebCodecs (both of which are in Chromium
M86).  So IETF 109 Hackathon might be a place to bring experimenters

Using the Trial tools, it should be possible to experiment with low-latency
streaming or realtime media over QuicTransport.  For example, it should be
possible to implement video upload by obtaining a codec bitstream using
WebCodecs, packetizing it using WebAssembly and then sending it using QUIC
datagrams or streams.

Playing with the technology might be helpful to understand its
architectural or performance limitations. For example, there are extra
memory copies in the Web architecture that typically aren't present in RTP
implementations.  For example, while there are zero-copy implementations of
QUIC, for security reasons there is an extra copy on receive or send within
QuicTransport in the browser; a copy when moving between Javascript and
WebAssembly; a copy when moving data to a Web Worker; a copy on capture; a
copy on rasterization (zero-copy rasterization tends to be unstable in the
browser), etc.

On Thu, Sep 17, 2020 at 6:30 AM Spencer Dawkins at IETF <> wrote:

> Hi, Bernard,
> On Tue, Sep 15, 2020 at 12:37 PM Bernard Aboba <>
> wrote:
>> 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,"
> Thanks for the clue here. I'd forgotten about ASAP(^), but my focus really
> is on the media.
>> [BA] The Automatic SIP trunking and Peering (ASAP) WG was subsequently
>> chartered:
>> but the charter seems to omit the media aspects that were discussed
>> during the RIPT BOF.
>> The HTTP/3 datagram draft (
>> (which
>> played a part in some of the scenarios described in the RIPT BOF) isn't
>> currently a WG work item anywhere, although
>> 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.
> Yeah, we're definitely experimenting with both. I'd like to talk to anyone
> else who is also experimenting (and can talk about it).
>>  In the W3C WebTransport WG (recently formed, see:
>> ) there is now a
>> work item for use cases. So perhaps some greater understanding will come
>> out of that.
> Thanks for the pointer. I was waiting for the final formation in W3C. I'll
> keep an eye on that.
> Best,
> Spencer
> * It was easier for me to keep track of BOFs that changed names when they
> were chartered when I was balloting on WG charters, but I'm not complaining
> that's ended!
>> <>
>> On Tue, Sep 15, 2020 at 8:42 AM Spencer Dawkins at IETF <
>>> 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}
>>> [2]
>>> [3]
>>> [4]
>>> _______________________________________________
>>> Audio/Video Transport Core Maintenance