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.
- Re: [dispatch] [Sframe] Dispatch of SFrame Bernard Aboba
- Re: [dispatch] [Sframe] Dispatch of SFrame Eric Rescorla
- Re: [dispatch] [Sframe] Dispatch of SFrame Sergio Garcia Murillo
- Re: [dispatch] [Sframe] Dispatch of SFrame Eric Rescorla
- Re: [dispatch] [Sframe] Dispatch of SFrame Bernard Aboba
- Re: [dispatch] [Sframe] Dispatch of SFrame Sergio Garcia Murillo
- Re: [dispatch] [Sframe] Dispatch of SFrame Eric Rescorla
- Re: [dispatch] [Sframe] Dispatch of SFrame Martin Thomson
- Re: [dispatch] [Sframe] Dispatch of SFrame Victor Vasiliev
- Re: [dispatch] [Sframe] Dispatch of SFrame Bernard Aboba
- Re: [dispatch] [Sframe] Dispatch of SFrame Eric Rescorla