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

[Richard Barnes <[e-mail]>]

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)

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.

--RLB

On Tue, Nov 16, 2021 at 1:51 PM Justin Uberti <
[e-mail]> 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 <[e-mail]> 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 <
>> [e-mail]> 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 <[e-mail]> 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
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/sframe
>>>>
>>> --
>> Sframe mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/sframe
>>
>