IETF Logo Mail Archive

Re: [AVTCORE] Interest in QUIC-SRTP (was: Re: Registering AVP Profiles for RTP over QUIC)

Roman Shpount <roman@telurix.com> Tue, 17 May 2022 05:43 UTC

Return-Path: <roman@telurix.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 249DFC079B47 for <avt@ietfa.amsl.com>; Mon, 16 May 2022 22:43:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.098
X-Spam-Level:
X-Spam-Status: No, score=-7.098 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 (1024-bit key) header.d=telurix.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 eWUD5DPaBXQI for <avt@ietfa.amsl.com>; Mon, 16 May 2022 22:43:12 -0700 (PDT)
Received: from mail-qk1-x72b.google.com (mail-qk1-x72b.google.com [IPv6:2607:f8b0:4864:20::72b]) (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 72298C19E84B for <avt@ietf.org>; Mon, 16 May 2022 22:43:12 -0700 (PDT)
Received: by mail-qk1-x72b.google.com with SMTP id n8so13837277qke.11 for <avt@ietf.org>; Mon, 16 May 2022 22:43:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=d4qdwcb4lpKyOMMZqywYEY1WnYbe0+Riz0icm8YN4NU=; b=svP+NyAutJNSkCpvj+fCUnkXOAK3ZdyytsYH2MynFDGjJYGt3WI3d4y939SsIarlg7 5Ceju2A0d1fpS15pes1/rao7ejUWTLNNmAqZTNainvRLVm4NTsVOIW/L79mIuq3sLRkh zs7JZ3Wh1veGJ/BOSArWG0BeXAq1+XjoRScjw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=d4qdwcb4lpKyOMMZqywYEY1WnYbe0+Riz0icm8YN4NU=; b=DDkhuUX/MbO005qnD9sp7t4+tOmig5yfLAxaAAEX6ExtJCndKNFOvfSsgMM0qmmW9r AvArUwMTbIC65q0WIwwNP0U44oqFDNnQtakcUEd/72Q6+Ct30rxsJ9Qnkbfx3jVarHqC Nk39BH2swJz7Ul/5uuDMnnAPZBZYXin9KW35BX81JxEsv9IZzljcLeihGmxlN6KEAf+D ygO1xPk8+aioJMVZ2QYyduvP08zCwOZGle1dLjQgQr0XfoFP64PGEGgBTJ8pUUy30413 DsE2SjdzuqRJB4D/3ULv9uZ1JUGvVzdULJ4p9YJ4HJmRzdouCy90yqI2iyXn57Ygdm8k oO1Q==
X-Gm-Message-State: AOAM533rNZ8f77MNWl9P1f1OGgthsy6keLBIgx75U5fusK0UMan2khOM I5pvnZsoPq9PwY0X5WcRIV641bZVtjMe1A==
X-Google-Smtp-Source: ABdhPJzH/gpyw1uaKNrMpHFedfjZzg2ZkWYOIfJwpRK00I1IeWoFlFeGHihJURuZ8UC0MMPM2raQxQ==
X-Received: by 2002:a37:a743:0:b0:69f:e64c:74c9 with SMTP id q64-20020a37a743000000b0069fe64c74c9mr15387531qke.432.1652766191287; Mon, 16 May 2022 22:43:11 -0700 (PDT)
Received: from mail-yw1-f177.google.com (mail-yw1-f177.google.com. [209.85.128.177]) by smtp.gmail.com with ESMTPSA id j28-20020a05620a147c00b0069fcc501851sm7057840qkl.78.2022.05.16.22.43.10 for <avt@ietf.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 16 May 2022 22:43:10 -0700 (PDT)
Received: by mail-yw1-f177.google.com with SMTP id 00721157ae682-2fefb051547so47808577b3.5 for <avt@ietf.org>; Mon, 16 May 2022 22:43:10 -0700 (PDT)
X-Received: by 2002:a0d:fa81:0:b0:2d6:faee:cbc4 with SMTP id k123-20020a0dfa81000000b002d6faeecbc4mr23604216ywf.388.1652766190420; Mon, 16 May 2022 22:43:10 -0700 (PDT)
MIME-Version: 1.0
References: <CAKKJt-dvotzuaK66T8WQd7YgNLNr_6vqa4W8-z=5FvujpGWA=A@mail.gmail.com> <CAD5OKxvuQ+ng4YUbKE2Do5aB3pOpTs24Y59G1-2QAwSSX6HYkw@mail.gmail.com> <CAKKJt-cXMa8bW7HhwrkzX2-O=kYK2GRNwtB+cHRB-zWn+f0f+g@mail.gmail.com> <CAD5OKxsPd8w=geXBjJwFSSNUhFQ3sc-MMvte3EG6w24=tMvVPQ@mail.gmail.com> <8d20301c-f227-4c0b-aaec-4f1ddf22f782@beta.fastmail.com> <CAOW+2ds4cp6Wgu88+riK5YVa8ywLKTe4jKSwKtV6q_aRTRaAbQ@mail.gmail.com> <CAD5OKxsFtCH19eOYQ-9TRE9uU9xfHGVqns_cALUJoTcjfWc1zg@mail.gmail.com> <CAKKJt-cFqTfwyMB66k9Hz+KXN6_07JQsJjbEvqd0DcJONkgA0w@mail.gmail.com>
In-Reply-To: <CAKKJt-cFqTfwyMB66k9Hz+KXN6_07JQsJjbEvqd0DcJONkgA0w@mail.gmail.com>
From: Roman Shpount <roman@telurix.com>
Date: Tue, 17 May 2022 01:42:59 -0400
X-Gmail-Original-Message-ID: <CAD5OKxumRemU3TYJed+kMmm+dxPMjuWgrb70wpb9UfBMb8B70Q@mail.gmail.com>
Message-ID: <CAD5OKxumRemU3TYJed+kMmm+dxPMjuWgrb70wpb9UfBMb8B70Q@mail.gmail.com>
To: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Cc: Bernard Aboba <bernard.aboba@gmail.com>, IETF AVTCore WG <avt@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000ad48e005df2e9d0c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/avt/frtgyeb79GlRS-lYoABckU4eT0Y>
Subject: Re: [AVTCORE] Interest in QUIC-SRTP (was: Re: 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 05:43:16 -0000

Understood. I did not want to hold back your work. I think I understood
your question about what is also possible a bit too broadly.

I think there was a bad precedent of UDP/TLS/RTP/SAVP, where RTP does not
run over TLS  or DTLS, and DTLS is only used for connection setup.
Considering the protocol design UDP/QUIC/RTP/AVP or UDP/QUIC/RTP/SAVP would
be the right AVP profiles that appropriately reflect the protocol layering.
_____________
Roman Shpount


On Mon, May 16, 2022 at 10:24 AM Spencer Dawkins at IETF <
spencerdawkins.ietf@gmail.com> wrote:

> The possibility of QUIC-SRTP has popped up a couple of times in threads
> about RTP over QUIC on this mailing list.
>
> I wouldn't dream of trying to discourage anyone from working on a protocol
> stack that meets their needs, so if there are people who think QUIC-SRTP is
> a worthy thing to specify, I'd encourage them to do so, but I'd ask that we
> discuss that separately in AVTCORE.
>
> If there was a good reason for AVTCORE to specify both RTP over QUIC and
> QUIC-SRTP, and that happened, that would be great, but I'd prefer that we
> avoid holding up work on both of these protocol stacks while we discuss
> which one would be better.
>
> Does that make sense?
>
> Best,
>
> Spencer
>
> On Wed, May 11, 2022 at 10:50 PM Roman Shpount <roman@telurix.com> wrote:
>
>> On Wed, May 11, 2022 at 9:31 PM Bernard Aboba <bernard.aboba@gmail.com>
>> wrote:
>>
>>>
>>>> [BA] On a spectrum of “add QUIC to an existing RTP/RTCP stack” (so as
>>> to be able to use P2P QUIC immediately without CC modifications) and “use
>>> QUIC for both media and data” (so as to simplify the stack), a QUIC-SRTP
>>> use cases falls somewhere in the middle, potentially lacking in both
>>> expediency and long-term simplicity.
>>>
>>>
>> I primarily wanted to point out that this option is possible, so when the
>> transport profile is defined it should be possible to specify it as well.
>> Essentially one can run (S)RT(C)P on top of QUIC or multiplex. The decision
>> if this option needs to be defined and implemented can be made at a later
>> date. I am not sure about your expediency and long-term simplicity claims.
>> Getting rid of SCTP would certainly be nice.
>> _____________
>> Roman Shpount
>>
>> _______________________________________________
>> Audio/Video Transport Core Maintenance
>> avt@ietf.org
>> https://www.ietf.org/mailman/listinfo/avt
>>
>

v2.23.0 | Report a Bug | By Email