Re: [dispatch] [Sframe] Dispatch of SFrame

Bernard Aboba <bernard.aboba@gmail.com> Tue, 16 June 2020 04:48 UTC

Return-Path: <bernard.aboba@gmail.com>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 981EA3A102F for <dispatch@ietfa.amsl.com>; Mon, 15 Jun 2020 21:48:24 -0700 (PDT)
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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6pnTlOqYjbiv for <dispatch@ietfa.amsl.com>; Mon, 15 Jun 2020 21:48:23 -0700 (PDT)
Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) (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 0020C3A102D for <dispatch@ietf.org>; Mon, 15 Jun 2020 21:48:22 -0700 (PDT)
Received: by mail-lj1-x232.google.com with SMTP id i3so17330200ljg.3 for <dispatch@ietf.org>; Mon, 15 Jun 2020 21:48:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=51YtsT86R0euVT3k2cWdgzHE+Eu6bN3UKGhZSfy5SMc=; b=dpBlaI54mi4mnuV9znpdjfkY4rJlCNkCxF/oQrlqxqOqe/NkACfOOMax+1ghbLKQ2i t9A8Cn7cG78LyJDEuPBwVhTU7+LjWH1PH03GPgKHYfrXFB5wZyRtUan7cf/Jff0cIe5n kPO1s/fhzInniG+4eRBSEgMERUtU9lzQAT4k5dOJyXz8zVMwSEy6B+YzwskbKm9L8VaY pNRBydKUdk04oRp8VuvbXpkc4z75H6KS49WON8qd9DGYfC6LrTu9WwpHwr8I8Kt5VHGr lNEpQ7Mq4FifdV0UaoO00uVGI+iHDUnYWbs3OkrnMKbq+ja7R2+y4GWXaHnb/FTatknW cMQw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=51YtsT86R0euVT3k2cWdgzHE+Eu6bN3UKGhZSfy5SMc=; b=bp/6OU6GjZ1KfFwhW1oVG3WINXtt6pwjwLfIAJo+zBUy2ik423B4CiIY+V3R6vr9Gs nA++VywMGQWp8IpTkrC+SxuWS1IUndFx049IzTorZr4Leo4M+8Sa83LDyhtB42LSWU8J pXiYivt5jW852N+an66ElYBo0iGcmKk2iWQx7OcNMWIdqjYg3TrW4yFzvT6cWhPLzXVQ tR7ERiVgEPjOidjWElZjUFku5fGEdENhBKk52lpfxhr16/rIPxjKn4fKs1W1IndcXJEe WSA7+xzEtbOeD0K+KxSjgzUbpmkhZm/29v1FGtj08RcbptDiiOClBlBUqgKiofXsy+bZ RwUA==
X-Gm-Message-State: AOAM530hM0sO6Z/Q160AeKY7dckKR3WZtWf2y3MdPTmsJzD+pXMTDjK1 E5qcUcmF4yMlPBbb+11yLBZ4NzifpX/g3gB5K2oLzuW9
X-Google-Smtp-Source: ABdhPJztmWW4vPuoeH7uyB4Iyn/+WLcS3MBsNTtWbsKZhUI9NBGKjDjEIuhHQOWoxsdIhKWK3hv6+gs8gbKxLt2F1Pg=
X-Received: by 2002:a2e:8e22:: with SMTP id r2mr506132ljk.240.1592282900508; Mon, 15 Jun 2020 21:48:20 -0700 (PDT)
MIME-Version: 1.0
From: Bernard Aboba <bernard.aboba@gmail.com>
Date: Mon, 15 Jun 2020 21:48:09 -0700
Message-ID: <CAOW+2dvDEThHXKGJNgSYe9bfj4HK44H6wQpdGYRutzwReg90OQ@mail.gmail.com>
To: DISPATCH list <dispatch@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000aab3e705a82c4023"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dispatch/b1VGhUgSYUVmb_UBoL4y2yPwEsk>
Subject: Re: [dispatch] [Sframe] Dispatch of SFrame
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dispatch/>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Jun 2020 04:48:25 -0000

Dr. Alexandre Gouailard said:

"With respect to PERC, SFrame is media transport agnostic, and would work
with QUIC, while PERC is RTP-based only.  Conferencing only, and assumes
SRTP."

[BA] Compared with PERC, SFrame is more efficient and transport agnostic,
more compatible with existing codec-independent SFUs, and more flexible in
terms of the scenarios it can potentially support.

The efficiency point is important for large scale deployments where even a
few percent savings in overhead or CPU consumption can translate to savings
of millions of dollars in bandwidth, hardware, etc.

Transport independence is inherent to the Web architecture, which via Media
Source Extensions (MSE) enables media to be transported and rendered via
any transport. This includes the WebRTC data channel (used by game
streaming services such as parsec) and QuicTransport (now in Origin Trial)
as well as today's more common http/https-based streaming mechanisms.
While MSE requires the media to be containerized, the WebCodecs API aims to
remove this restriction. Since only RTP utilizes SRTP, a transport
independent solution cannot be tied to SRTP as PERC double is.

Seamless integration with SFUs is also a major advantage. Assuming that the
SFU is already codec agnostic (e.g. uses framemarking or the dependency
descriptor to forward), very little code (or none) needs to be changed
within the SFU, which can continue to do things such as SSRC translation
that are prohibited in PERC.  In addition, SFrame does not require that the
SFU make any modifications to its robustness code (RTX, FEC or RED).
Incompatibility with existing SFUs (and RTP implementations in general) was
one of the major objections to PERC pointed out in IETF last call.  For
this reason alone, PERC will never be widely deployed.

Finally, SFrame is not tied to a key management scheme, which allows it to
be potentially adapted for use in scenarios which may have quite different
threat models.  This may include 1-1 calls, conference calls, partially or
fully anonymous meetings (where some media streams may not be available to
some participants), and "protected meetings" (where the recordings are
protected from modification).  Several commenters in IETF last call pointed
out scenarios in which the PERC threat model was insufficient (e.g. PERC
allows participants to impersonate each other).

In addition, the lack of a key management tie-in in SFrame allows for
multiple deployment models, where components of the system may be
integrated within the client, or deployed in an on-premise or cloud server,
or some hybrid of these.

In short, SFrame is simultaneously more efficient, more flexible, more
compatible and more deployable than PERC.