Re: [rtcweb] New use-case proposed

Justin Uberti <juberti@google.com> Fri, 11 May 2012 14:24 UTC

Return-Path: <juberti@google.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9189421F86E1 for <rtcweb@ietfa.amsl.com>; Fri, 11 May 2012 07:24:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.829
X-Spam-Level:
X-Spam-Status: No, score=-101.829 tagged_above=-999 required=5 tests=[AWL=-0.519, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N6e0v4TFOxdr for <rtcweb@ietfa.amsl.com>; Fri, 11 May 2012 07:24:35 -0700 (PDT)
Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8E7AA21F86E3 for <rtcweb@ietf.org>; Fri, 11 May 2012 07:24:35 -0700 (PDT)
Received: by qcsq13 with SMTP id q13so2409833qcs.31 for <rtcweb@ietf.org>; Fri, 11 May 2012 07:24:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=KQ//wLydbgrnnPYV5YfxLu8T71SLO0Y+9kiMZIM3dE4=; b=a5I0SmqqzDq9BT0Vte4x/Bkr3JUMSYk842LeIrnNE9m5UYXKmvVnwnk5RnlExu4IY1 qXPFRaispckBTAI5MSyHxKjnChF5KQ7A8QV2u3yNlV55QkSnTq8YX5Dzj3LhwXObZY6o WKHvHJGvJUYo8qn02YrMvlqhU2ClfpLbki4Eh/NJVQwVPfcSH/ZwF683vGMLZFeCnOAv VnZr37Qn+Dlj4W77fqZZ7b7YSes8CjQ5KIkcA6hwJ2T2GAEU9a8r8yVI5mPul9hFV7Ss QeFPRc7/WCw8v57iTSx2qfPQ7nKasuo3XiURZGvrecptGO+KzHwE4KievgiJJ+4EzpAH QStQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=KQ//wLydbgrnnPYV5YfxLu8T71SLO0Y+9kiMZIM3dE4=; b=g+4XsnzCJ6q2g8oXFBjErw3ipiyFEfXQR6gEI8bFcTYoIgB5jNFfQhbAnDgJSB6/h9 8H7tQJffzOaSNSkWzB449sknLY/WFvTl6gTTWLnbhMZn8JV9vAW5HSfuTI1W8EGvpQpL abn/Mzeqhnc5MlMzV+saX+FL21+t+MY6x5FH2QUI3nPYq4ThN3biGbwsaJqacMnvcFvW 2eSo3EZZ9f1zz4LQdOFQUgcv0mt3USTOIFZA2pKWyFbD7Pxvn0fhmCDZ1gEyaE3P3IvM giv2oFdD78xM8eAJHsYhmCN6Z4Xsr5v3VMgQsgzzYrlB+0SGuXb7rBCZPHLQx3E/+Df8 xY1Q==
Received: by 10.224.219.144 with SMTP id hu16mr18210025qab.97.1336746272686; Fri, 11 May 2012 07:24:32 -0700 (PDT)
Received: by 10.224.219.144 with SMTP id hu16mr18209970qab.97.1336746272206; Fri, 11 May 2012 07:24:32 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.217.129 with HTTP; Fri, 11 May 2012 07:24:12 -0700 (PDT)
In-Reply-To: <4FAD0D8C.7020701@ericsson.com>
References: <4FAD0D8C.7020701@ericsson.com>
From: Justin Uberti <juberti@google.com>
Date: Fri, 11 May 2012 10:24:12 -0400
Message-ID: <CAOJ7v-3FP3pJDBx71E_N7cssnf90Qb2bCxnXeBkw386ZxsLcZw@mail.gmail.com>
To: Stefan Hakansson LK <stefan.lk.hakansson@ericsson.com>
Content-Type: multipart/alternative; boundary=20cf3074b596b5b1a404bfc37e64
X-System-Of-Record: true
X-Gm-Message-State: ALoCoQmEutQIa8khf8H6RHZ5X5pJxrPG/rlUvZwkkWi4mdJ98VX/og9rhP9hMeD8JsDxs/Q3P7QHUGIIpaHJTokqqLrZMk+XxuU0bCbX6LbblERDQpGsFGJXy4EMJx9f/n0NG5cpZ3Is
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] New use-case proposed
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 11 May 2012 14:24:36 -0000

SRTP encryption is cheap, practically free on today's CPUs. I agree with
the general use case but I don't agree with the conclusion that we need to
require that the middlebox does not rewrite packets or perform crypto,
mainly since it will increase system complexity (and the system is already
quite complex).

On Fri, May 11, 2012 at 9:01 AM, Stefan Hakansson LK <
stefan.lk.hakansson@ericsson.com> wrote:

> I've been sketching on a new use-case. The use-case is intended to
> derive requirements that enable low complex central nodes for multi
> party sessions, which in turn leads to requirements regarding
> (essentially) keying solution for SRTP and the possibility for the app
> to control/set things in the media configuration (in other words, for
> JSEP):
>
>
> Multi-party with low complexity central node
> ==============================**================
>
> A geographically spread (charity, non-profit, school) organization
> offers its members multi-party video communication via a shared virtual
> room that participants can enter and leave at any time. At times there
> are many persons in the virtual room (20+), at other times very few
> (3-5, or even 0-1).
>
> The application will control if few participants (a subset) are shown at
> a higher fidelity or if many (all) are shown at a lower fidelity or a
> mix of some few at high fidelity and the rest at much lower fidelity
> given the existing bandwidth limitations between participants.
>
> Since there are at times many persons in the virtual room, it is not
> feasible to set up a mesh. The bandwidth needed by a participant exceeds
> what many members have access to, especially in their uplinks, so
> instead a central media node is deployed. In addition, the organization
> does not have access to much funds, but has to rely on cheap hardware
> (often donated) operated by volunteers.
>
>  From this use-case a high level requirement saying something like
>
> "It must be possible to set up media streams and encryption in such
> a way that processing in a central node is minimized (no transcoding
> required, no RTP packet rewriting, no decryption/re-encryption for every
> outgoing flow - just simple forwarding)."
>
> can be derived. This can in turn be broken down into more detailed
> requirements such as:
>
> - The keying solution must allow each participants to encrypt to
> multiple receivers without any decryption+encryption in the middle node
>
> - RTP sessions that have SSRCs from multiple PeerConnections being
> interconneted must be supported. From a given end-point all SSRCs will
> come over one PC, but the full path will be different towards different
> sets of SSRCs.
>
> - Signalling must be capable of establishing a common set of receiver
> configurations over all participants.
>
> - The API must allow for the above, i.e.:
> -- The app must be able to chose a keying solution that enables
> encryption to multiple receivers (if the app can have any control over
> keying method used)
> -- The app must be able to control SSRCs to use for outgoing streams
> -- The app must be able to control the receiver configuration the
> browser uses
>
> Is this something we should consider adding to the use-case document?
>
> Br,
> Stefan
> ______________________________**_________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/**listinfo/rtcweb<https://www.ietf.org/mailman/listinfo/rtcweb>
>