IETF Logo Mail Archive

Re: [AVTCORE] Registering AVP Profiles for RTP over QUIC

Bernard Aboba <bernard.aboba@gmail.com> Tue, 17 May 2022 03:28 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 80893C079B54 for <avt@ietfa.amsl.com>; Mon, 16 May 2022 20:28:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 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, MIME_QP_LONG_LINE=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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lKQXh5bLueMv for <avt@ietfa.amsl.com>; Mon, 16 May 2022 20:28:25 -0700 (PDT)
Received: from mail-ot1-x335.google.com (mail-ot1-x335.google.com [IPv6:2607:f8b0:4864:20::335]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCED6C20D671 for <avt@ietf.org>; Mon, 16 May 2022 20:28:25 -0700 (PDT)
Received: by mail-ot1-x335.google.com with SMTP id m15-20020a9d608f000000b00606a788887aso11394159otj.0 for <avt@ietf.org>; Mon, 16 May 2022 20:28:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:content-transfer-encoding:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=ZvNpwkHutc6tmCW6VtGWU7QOs2he3AxjpTZsb6bgoEA=; b=PZtJXVNCBvQhBt8WdM3D/qJ/qzCc6D42sgUyHAwjoF1+BXOK7oJYLyDKsWCxf/gjgs TieHk4chvdyH4MooyW1uR9mHToSkcSMpnsOGFlhxhCBodm14WfXM+HhhkUo5SGVRvccu gRVI0YFF1aC99RiFxuAPiL/7jwCvx6nUk0YhtzpckIJeUZlTw3nDlEuTEeUz169ygtT3 LO/DANOGAL9cjAdt6dkX5dzDmxkywfmdX8UNJNhRuaU/9F/OKYicOv3l3+01lCsnKeOq ZOzarj7kv/PXKrNKQfu7T2vuV1oJrPH1CUWxWgMzcI1zUwGhUK/4yMp2HWVnHOa1Kv5E 4SGA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=ZvNpwkHutc6tmCW6VtGWU7QOs2he3AxjpTZsb6bgoEA=; b=gOnF7KNSfYXXsoT5jtknC7qVtJUpyyr5ATEK6oZrcQx4VZ/n/WJPz43Hx7zPHMmvHH 7wcyLx/ZIhaxdOsWPwaRXaqfJ7CiSm2aOLxiYmG7jcvp1ktJw8LF+ymmw56yyDAkpbMC iKYbm5H19vJKr3n/WIqZpqGxVlSammXY8P3G2ZJZayBccUzK0DiTPmxnEuAVwTYbzO5e daE1/nu1ixa0g52YKiaiUzAd2sFN007AEMjT4mwJfznpOOmPNP4rl40jwbyQibC/7R62 7X/mtcA9B4Ie/sqT3JegD49wn6+PYp1sbE9LyvGxlJP4sMBq5JEK1sRl2ycqS0O507gC 2rYA==
X-Gm-Message-State: AOAM532j0KzUHTeUwUevrSwLshXu6Atk++k4zBiCIMBxYp1BEkjgpt8Z MWesgJ3T7rJg0niZjTRgigXpOG1dSt4=
X-Google-Smtp-Source: ABdhPJwR1/c+lBLAB7u0uRAZnSurm/mM6dJ8BcSVDhCA+VjcRykM0aKpCqSk9cnnamfyRRugBpQrmw==
X-Received: by 2002:a05:6830:2b13:b0:606:56ab:d5e9 with SMTP id l19-20020a0568302b1300b0060656abd5e9mr7186042otv.157.1652758104457; Mon, 16 May 2022 20:28:24 -0700 (PDT)
Received: from smtpclient.apple (c-24-16-156-188.hsd1.wa.comcast.net. [24.16.156.188]) by smtp.gmail.com with ESMTPSA id bi5-20020a056808188500b00325cda1ff96sm4729802oib.21.2022.05.16.20.28.23 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 16 May 2022 20:28:24 -0700 (PDT)
From: Bernard Aboba <bernard.aboba@gmail.com>
X-Google-Original-From: Bernard Aboba <Bernard.Aboba@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail-81F08E3B-FA3D-403E-A6EB-0D59EA40E818"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (1.0)
Date: Mon, 16 May 2022 20:28:22 -0700
Message-Id: <B67D25D5-87D0-42A8-BA6E-FEE6EF178E83@gmail.com>
References: <CAD5OKxs66qObT3YY-FNuxNE_5cE6TwqWt-W4vzWKNCP=x70SWg@mail.gmail.com>
Cc: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>, IETF AVTCore WG <avt@ietf.org>
In-Reply-To: <CAD5OKxs66qObT3YY-FNuxNE_5cE6TwqWt-W4vzWKNCP=x70SWg@mail.gmail.com>
To: Roman Shpount <roman@telurix.com>
X-Mailer: iPad Mail (19E258)
Archived-At: <https://mailarchive.ietf.org/arch/msg/avt/6VxsM8nUgkNsnybDUuQPLeRAcRI>
Subject: Re: [AVTCORE] Registering AVP Profiles for RTP over QUIC
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.34
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, 17 May 2022 03:28:29 -0000

On May 16, 2022, at 19:46, Roman Shpount <roman@telurix.com> wrote:
> 
> 
> Hi Spencer,
> 
> One more question: How would you signal RTP over QUIC when it is encapsulated using the RFC 4571 framing method? Is it going to be TCP/QUIC/RTP/AVPF?
> 
> You would end up with this encoding when RTP over QUIC is used on top of TCP, and only the ICE-TCP candidate is present.

[BA] How is this different from RFC 4751 framing (RTP over TCP)?  There’s no QUIC involved, right? 

> 
> Should normal encoding be UDP/QUIC/RTP/AVPF so it would match?
> _____________
> Roman Shpount
> 
> 
>> On Wed, May 11, 2022 at 4:47 PM Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> wrote:
>> Dear AVTCORE, 
>> 
>> I've had an open PR in https://github.com/SpencerDawkins/sdp-rtp-quic/pull/9 for a while,so I could get a sense of how AVT profiles are supposed to work, and I'd like to push on that now (with a virtual interim meeting coming up next week).. 
>> 
>> The high-level summary of discussion in https://github.com/SpencerDawkins/sdp-rtp-quic-issues/issues/5 (note that this discussion is in a different repo, because reasons) has been roughly,"what's the difference between QUIC/RTP/AVPF and QUIC/RTP/SAVPF"?
>> 
>> The arguments about not registering secure AVP profiles involve 
>>  the computational overhead of double encryption for all packets, plus
>> the payload overhead of 10 bytes per packet since you have 2 HMACs.
>> The arguments about registering secure AVP profiles seem to revolve around 
>> Minimizing the impact of added QUIC support in existing implementations that are using /RTP/SAVPF now.
>> QUIC encryption protects payloads between QUIC endpoints, but there are many multi-endpoint RTP topologies (https://www.rfc-editor.org/rfc/rfc7667 has about 50 pages of them), and when a middlebox receives  QUIC/RTP/AVPF, it's not obvious whether the middlebox should
>> forward the RTP payload using  RTP/AVPF (where the outgoing AVPF matches the incoming AVPF), or 
>> forward the RTP payload using RTP/SAVPF, where the outgoing SRTP encryption matches the incoming QUIC 
>> It seems to me that there are three choices:
>> Use only QUIC/RTP/AVPF, and and require middleboxes receiving  QUIC/RTP/AVPF traffic to always forward that traffic over RTP/SAVPF
>> Use only QUIC/RTP/AVPF, and and require senders to signal middleboxes whether they should forward that traffic over RTP/AVPF or RTP/SAVPF
>> Register both QUIC/RTP/AVPF and QUIC/RTP/SAVPF, and if you have to do double encryption on the QUIC/RTP paths to get RTP/SAVPF on the other side of a middlebox, too bad
>> So, my questions are, 
>> What am I missing here?
>> Are any of the choices I'm listing obviously the BEST choice?
>> Best,
>> 
>> Spencer
>> _______________________________________________
>> Audio/Video Transport Core Maintenance
>> avt@ietf.org
>> https://www.ietf.org/mailman/listinfo/avt
> _______________________________________________
> Audio/Video Transport Core Maintenance
> avt@ietf.org
> https://www.ietf.org/mailman/listinfo/avt

v2.23.0 | Report a Bug | By Email