Re: [AVTCORE] QUIC RTP Tunnelling

Samuel Hurst <samuelh@rd.bbc.co.uk> Mon, 02 November 2020 16:39 UTC

Return-Path: <samuelh@rd.bbc.co.uk>
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 926FE3A0CD8 for <avt@ietfa.amsl.com>; Mon, 2 Nov 2020 08:39:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.148
X-Spam-Level:
X-Spam-Status: No, score=-2.148 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.247, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 UaN_9hh1PDRq for <avt@ietfa.amsl.com>; Mon, 2 Nov 2020 08:39:31 -0800 (PST)
Received: from tlsmtp.bbc.co.uk (tlsmtp1.telhc.bbc.co.uk [132.185.161.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 476683A0B3C for <avt@ietf.org>; Mon, 2 Nov 2020 08:39:31 -0800 (PST)
Received: from gateh.lh.bbc.co.uk ([10.118.193.77]) by tlsmtp.bbc.co.uk (8.15.2/8.15.2) with ESMTPS id 0A2GdSv3004112 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Nov 2020 16:39:29 GMT
Received: from mailhub0.rd.bbc.co.uk ([172.29.120.128]) by gateh.lh.bbc.co.uk (8.14.5+Sun/8.13.6) with ESMTP id 0A2GdStC004320; Mon, 2 Nov 2020 16:39:28 GMT
Received: from [172.29.197.137] (port=57818) by mailhub0.rd.bbc.co.uk with esmtp (Exim 4.92) (envelope-from <samuelh@rd.bbc.co.uk>) id 1kZcrf-0000dH-SQ; Mon, 02 Nov 2020 16:39:28 +0000
To: Bernard Aboba <bernard.aboba@gmail.com>, avt@ietf.org
References: <8dd07103-16a0-ca03-625b-e6c2b4c18008@rd.bbc.co.uk> <91C47627-9EA3-4C01-9ADD-E7AAE103AD2B@gmail.com>
From: Samuel Hurst <samuelh@rd.bbc.co.uk>
Autocrypt: addr=samuelh@rd.bbc.co.uk; prefer-encrypt=mutual; keydata= LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCgptRE1FWFZacHVSWUpLd1lC QkFIYVJ3OEJBUWRBTC9KNCtaMUVGRGNLR3ByNzdvYzZKRWVOemZXQ0t4VXBCNXJ6CnVUN0tm dHEwSTFOaGJYVmxiQ0JJZFhKemRDQThjMkZ0ZFdWc2FFQnlaQzVpWW1NdVkyOHVkV3MraUpZ RUV4WUkKQUQ0V0lRUi9NaG1CLzJtREdicVJEUUZGM3RxdVp0UWdLd1VDWFZacHVRSWJBd1VK Q1dZQmdBVUxDUWdIQWdZVgpDZ2tJQ3dJRUZnSURBUUllQVFJWGdBQUtDUkJGM3RxdVp0UWdL L0p6QVFEZUxZZjNSQVgzOTk3THgzcDZnbTZQClRCYlJSV2JVeDJ0VHovOTFzQytUREFFQTVz di9GdFdNN045VS83L0p2MDdQVkpGS0VTS3JQRENFdHBDSHdwbG0KblF5NE9BUmRWbW01RWdv ckJnRUVBWmRWQVFVQkFRZEFnVWpnZ09jb25pV0RFWkxQazBQNHVvRGtGMmZubFR1egpmSVpl dm9kTGhBNERBUWdIaUg0RUdCWUlBQ1lXSVFSL01obUIvMm1ER2JxUkRRRkYzdHF1WnRRZ0t3 VUNYVlpwCnVRSWJEQVVKQ1dZQmdBQUtDUkJGM3RxdVp0UWdLNys4QVFETFZlaW9rVlBIaUlG TXpWRzltS2dib3A1am1CQkkKazFpUWw5d0NJMVFOUVFEK0x1LzhRZnJPcjBSOGNEemUxSjlW Q0VmQmVjcjdROElHcVhCWHpZWkU4QTA9Cj1UNFJwCi0tLS0tRU5EIFBHUCBQVUJMSUMgS0VZ IEJMT0NLLS0tLS0K
Message-ID: <de22c2fb-0c50-6c31-82b7-cb100c348964@rd.bbc.co.uk>
Date: Mon, 2 Nov 2020 16:39:24 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <91C47627-9EA3-4C01-9ADD-E7AAE103AD2B@gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="KmqLaRjBBohCFhbMGFfWcy7GZeqo06XUI"
Archived-At: <https://mailarchive.ietf.org/arch/msg/avt/WpULiHZWdokMPyrO6A1LKVKzg28>
Subject: Re: [AVTCORE] QUIC RTP Tunnelling
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: Mon, 02 Nov 2020 16:39:33 -0000

Hello Bernard,

On 02/11/2020 15:29, Bernard Aboba wrote:
> A comment on the allocation of QUIC datagram flow identifiers. In pooled
> transports such as HTTP/3 over QUIC, the datagram flow identifier is
> used to route datagrams to a particular application, and an additional
> identifier is provided by the application to identify a particular flow.
> Therefore in a pooled transport the application will not have the
> ability to allocate its own application flow identifiers.

In order to keep the initial draft more concise, I've written it as if
the only thing that goes over the QRT session is just RTP, so I can
avoid having to specify managing different applications contending for
the same space.

However, I fully realise that in the future the draft will absolutely
have to support co-located application packet flows. I can forsee this
causing issues with things like SDP which advertise the flow identifiers
up front, but that's why I made it an optional component of the draft.

I'm keeping an eye on the development of such ideas in the DATAGRAM and
H3 DATAGRAM spaces to see what the consensus ends up being, and then I
can adopt that.

-Sam