Re: [Sframe] Proposal: SFrame && SPacket && !SIDU

Justin Uberti <juberti@alphaexplorationco.com> Tue, 16 November 2021 22:21 UTC

Return-Path: <juberti@alphaexplorationco.com>
X-Original-To: sframe@ietfa.amsl.com
Delivered-To: sframe@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F5B23A09FA for <sframe@ietfa.amsl.com>; Tue, 16 Nov 2021 14:21:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.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, 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=alphaexplorationco.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 5kn3L6Mz59VU for <sframe@ietfa.amsl.com>; Tue, 16 Nov 2021 14:21:52 -0800 (PST)
Received: from mail-oi1-x22b.google.com (mail-oi1-x22b.google.com [IPv6:2607:f8b0:4864:20::22b]) (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 995503A09F7 for <sframe@ietf.org>; Tue, 16 Nov 2021 14:21:52 -0800 (PST)
Received: by mail-oi1-x22b.google.com with SMTP id s139so1662359oie.13 for <sframe@ietf.org>; Tue, 16 Nov 2021 14:21:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alphaexplorationco.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=QaVLKWH1Kp4+Q3/xYXdGhhGTCF1yTP9dgB8B38kJ18Y=; b=gB3BOw1l/4L5c95DvAxBDhLygaS6bWLR0GH1EMgWRGLvUTMDnMUlTSsuJmMb3sxsOu 7OAJHPR34yKaxpuRSTvcxZDxOLwLSY16nDSOSfpAG4SFg1I1/EbsSRCwgme1dBoMQJIj CXDwaiT1hJADo/j1Mrz3H7qh7R06AeWg6Ys40ZCCvk4dpej4AzRbU3zn9NOzqPIMNHlF 4S66HEDorBMUwa7vWgnZ+T3Mi17E8r8asUkurN0z2XA62E6NxFDnfGuXCkW0eMs6FAJu Gkwn77zyyMawC50S1mnlAD9DTP3LjfPO2rHZerl9t2ISiXB2zeILX2PuwAMi2DC99L7s bEgg==
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=QaVLKWH1Kp4+Q3/xYXdGhhGTCF1yTP9dgB8B38kJ18Y=; b=g8nnCI+1+TFyR5qOyP5vZsGL8Pa3v1GVMG80bgqt1Q62p5FddyrJ1HycZmC4iUfnPF ONZJhm/+uN2Nb3hl739w3eC85Sje0Sax7T24O37qKzT7ycgQimZ61WppDzApqhrHVg6R SyV744SX/rWrcVqmCyF495+th5ItL6FhaaChV7se4k9KyHqDYWa+R+e45JULvTxG0mBn LTOR/4dAjxAZDF40coZeG7AwFeKHggFE8wklB5zyuqNV2FahI6ncgS3geESGXdyqZdt4 qh5mxCBiyPgPVilPe71JESuBgbmVc+u1MlvvkLus+ReC9NE4mVWxXBPUcTec2eP0lIKK HEQA==
X-Gm-Message-State: AOAM531STh5lx+mQesCN6GAi/Fs72U7fMk9u8Dx1gLDMOYnvNNOY6+au p10CbfLbFsw74rkib4q1DLTWV2Mtn/V2JCXh/ewcjw==
X-Google-Smtp-Source: ABdhPJz/bEh7y1jvKFr8vmd0QgQzZV1I8EZpQJUgwwhdglk3dLpUzmG+/HJT+623FA0RBcVg4s986b1k/CfzHGCd4Ds=
X-Received: by 2002:a05:6808:53:: with SMTP id v19mr23494459oic.8.1637101310656; Tue, 16 Nov 2021 14:21:50 -0800 (PST)
MIME-Version: 1.0
References: <CAL02cgSytJSLPziTzTOAQZFke47YrhdS381b4OmqcMPM1=Nzbw@mail.gmail.com> <CANRTqcNATCQcSyTr9Vcs3Y9uMJ1f_4FDKGo6idF9D+9ae+SX9g@mail.gmail.com> <CAL02cgRmgOn1bvzLY4aFojYh306O6-BxJ3B_5Agq5KVEypACSg@mail.gmail.com> <CAOLzse1pkHGK0Nfyy9iT7yPHGdShwPYjL-CUPqMputC=Z_QYiQ@mail.gmail.com> <CAL02cgQJF8xz3eXK9ytoujuH2kB8z0yUb8T4wmz7tnu57eNdCQ@mail.gmail.com>
In-Reply-To: <CAL02cgQJF8xz3eXK9ytoujuH2kB8z0yUb8T4wmz7tnu57eNdCQ@mail.gmail.com>
From: Justin Uberti <juberti@alphaexplorationco.com>
Date: Tue, 16 Nov 2021 14:21:40 -0800
Message-ID: <CAOLzse1LZwzhVsJeo5PO5JxHfVUo_cc7+guZfZmNt7yyX4QbmA@mail.gmail.com>
To: Richard Barnes <rlb@ipv.sx>
Cc: Sergio Garcia Murillo <sergio.garcia.murillo@cosmosoftware.io>, sframe@ietf.org
Content-Type: multipart/alternative; boundary="0000000000001555c405d0ef5aae"
Archived-At: <https://mailarchive.ietf.org/arch/msg/sframe/m1VOD2uKVrJQ4coV2BdQXgvM4q0>
Subject: Re: [Sframe] Proposal: SFrame && SPacket && !SIDU
X-BeenThere: sframe@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Secure Media Frames <sframe.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sframe>, <mailto:sframe-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sframe/>
List-Post: <mailto:sframe@ietf.org>
List-Help: <mailto:sframe-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sframe>, <mailto:sframe-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Nov 2021 22:21:58 -0000

On Tue, Nov 16, 2021 at 1:33 PM Richard Barnes <rlb@ipv.sx> wrote:

> Specifically, I mean the things that are AEAD-encrypted.
>
> My mental model is that there are two moving parts here:
> 1. A general SFrame encapsulation, defined in this group, that takes a
> "unit" of media data and encrypts it with an AEAD cipher
> 2. One or more ways to apply that encapsulation to a real-time media
> stream.
>
> Since AEADs deal with discrete quantities of data and not streams, one of
> the things (2) has to define is how to divide a media stream up into units
> that are fed into the SFrame encap/decap algorithms.  (In other words,
> between which layers in the media stack you put in the SFrame layer.)  And
> on decode, you need a way for the receiver to recognize when SFrame
> ciphertexts begin and end.
>
> For SFrame and SPacket, those answers are pretty clear:
> * For SPacket: SFrame goes between packetization and SRTP; ciphertext
> begin/end = packet begin/end
> * For SFrame: SFrame goes between encoding and packetization; ciphertext
> begin/end = packet begin/end (with generic depacketizer)
>

Makes sense, but these are two very different things (although I suppose
they may largely reduce to the same thing in trivial cases such as G.711).
For one, SFrame requires defining some sort of generic packetization,
whereas SPacket seems like it would reuse existing RTP packetization and
dependencies.


>
> Those answers would be appreciably more complicated and codec-dependent if
> we try to develop an SIDU approach as well as SFrame/SPacket.  Thus my hope
> of ruling it out of scope.
>

While I appreciate the desire to cut scope, to me SIDU is just a slight
refinement of SFrame. IDUs are frames, after all.

>
> --RLB
>
> On Tue, Nov 16, 2021 at 1:51 PM Justin Uberti <
> juberti@alphaexplorationco.com> wrote:
>
>> Richard, when you talk about "units" here, are you referring to things
>> coming out of the codec? or the RTP packetizer for said codec?
>>
>> The recent IETF meeting ended with some confusion as to this specific
>> question and it would be good for us on this list to make sure we're all in
>> alignment.
>>
>> On Tue, Sep 7, 2021 at 12:46 PM Richard Barnes <rlb@ipv.sx> wrote:
>>
>>> I'm not totally sure what you mean by "spatial frames" here; looks like
>>> the notion varies some by codec.  Assuming "spatial frames" are frames in
>>> the sense of "something that comes out of depacketizater", I think we're
>>> probably on the same page.
>>>
>>> Maybe it would be clearer to state the proposal as: Encryption is done
>>> in units of whole RTP payloads.  One payload for SPacket; all payloads in
>>> the frame for SFrame.  We would not support cases where an encrypted unit
>>> would span a partial RTP payload.  For example:
>>>
>>> NOT OK
>>> Payload 1: First part of SFrame unit A
>>> Payload 2: Second part of A, first part of B
>>> Payload 3: Second part of B
>>>
>>> OK
>>> Payload 1: SFrame unit A
>>> Payload 2: First part of Sframe unit B
>>> Payload 3: Second part of B
>>>
>>> Does that line up with what you have in mind?
>>>
>>> --Richard
>>>
>>> On Mon, Sep 6, 2021 at 2:53 PM Sergio Garcia Murillo <
>>> sergio.garcia.murillo@cosmosoftware.io> wrote:
>>>
>>>> Hi Richard,
>>>>
>>>> Just one minor comment, the "media frames", should be spatial frames if
>>>> SVC is used so an SFU is able to not forward all spatial layers to the
>>>> receiver. Apart from that, I am ok with removing "SIDUs" from the scope.
>>>>
>>>> Best regards
>>>> Sergio
>>>>
>>>> On Thu, Sep 2, 2021 at 10:20 PM Richard Barnes <rlb@ipv.sx> wrote:
>>>>
>>>>> Hi folks,
>>>>>
>>>>> I'd like to see if we can agree to limit our scope a bit.  There has
>>>>> been discussion of multiple levels at which SFrame could be applied:
>>>>>
>>>>> * "SFrame" - Whole media frames
>>>>> * "SPacket" - Individual RTP media payloads
>>>>> * "SIDU" - Some codec-specific "independently decodeable units"
>>>>>
>>>>> I'd like to propose that we take "SIDU" off of the table, but keep the
>>>>> other two.
>>>>>
>>>>> It seems like SFrame and SPacket both have strengths in certain
>>>>> scenarios (depending on how you want to trade off bandwidth vs.
>>>>> complexity), but they're both pretty straightforward in terms of how they
>>>>> integrate with the media processing pipeline.  In particular, they don't
>>>>> have any codec-dependence.  SIDU, by contrast, seems like a world of pain.
>>>>> It requires that the encryption scheme be entangled with the codec, which
>>>>> requires special per-codec integration logic in the specifications.  And
>>>>> the bandwidth gains for all that complexity are not that large.
>>>>>
>>>>> Is there anyone here who feels that SIDU is something this group needs
>>>>> to spend time specifying?
>>>>>
>>>>> --Richard
>>>>> --
>>>>> Sframe mailing list
>>>>> Sframe@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/sframe
>>>>>
>>>> --
>>> Sframe mailing list
>>> Sframe@ietf.org
>>> https://www.ietf.org/mailman/listinfo/sframe
>>>
>>