Re: [rtcweb] To multiplex or not!

Matthew Kaufman <matthew.kaufman@skype.net> Tue, 19 July 2011 16:40 UTC

Return-Path: <matthew.kaufman@skype.net>
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 C5C021F0C40 for <rtcweb@ietfa.amsl.com>; Tue, 19 Jul 2011 09:40:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IXEHOktoTBPn for <rtcweb@ietfa.amsl.com>; Tue, 19 Jul 2011 09:40:38 -0700 (PDT)
Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id 7FFCE1F0C37 for <rtcweb@ietf.org>; Tue, 19 Jul 2011 09:40:38 -0700 (PDT)
Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id 9D09416F7; Tue, 19 Jul 2011 18:40:37 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=mx; bh=nVc4f8APdqWbkm zQQ3gGxbYDo+U=; b=RGLo5s60G7L9Gc9xXZdwpInaA05yjZDyz2Go+Zzhr05PI7 mAGvEdPJPrVkQsg8MIe3mFKVkm170j/6CWBoKbSrNugNCoiIT3Yhb0e3HU1FH1OE 1tpXsFfyBnjyDhhnhfsTWcUsFbLpWszkRNsyGIrOG9CYQ21iNZ9u6CdUBnh9A=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=skype.net; h=message-id:date:from :mime-version:to:cc:subject:references:in-reply-to:content-type: content-transfer-encoding; q=dns; s=mx; b=foN4QckAQUAPl8DTMJ6af/ wbi4YdoUZmBVg52TN36q4IsgT2KwXEyPsV2x43UlWBqA/BpTq7TmSJYqDlL/prKK 0sMKz93y0O93Hw2cTtLroDTCWdQPCn2XbBILaPv7lYT25QtIIGOGi6RP3ZBtSSaj Mq/2/IW8VYoZ1qmjbnCPg=
Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id 9B6EB7FC; Tue, 19 Jul 2011 18:40:37 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id 7089135080A4; Tue, 19 Jul 2011 18:40:37 +0200 (CEST)
X-Virus-Scanned: amavisd-new at lu2-zimbra.skype.net
Received: from zimbra.skype.net ([127.0.0.1]) by localhost (zimbra.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ii-WlTaSLTh; Tue, 19 Jul 2011 18:40:36 +0200 (CEST)
Received: from [10.10.155.2] (unknown [198.202.199.254]) by zimbra.skype.net (Postfix) with ESMTPSA id 5AA203507EA9; Tue, 19 Jul 2011 18:40:36 +0200 (CEST)
Message-ID: <4E25B37D.9080404@skype.net>
Date: Tue, 19 Jul 2011 09:40:29 -0700
From: Matthew Kaufman <matthew.kaufman@skype.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11
MIME-Version: 1.0
To: Magnus Westerlund <magnus.westerlund@ericsson.com>
References: <4E259484.20509@ericsson.com>
In-Reply-To: <4E259484.20509@ericsson.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] To multiplex or not!
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: Tue, 19 Jul 2011 16:40:44 -0000

On 7/19/2011 7:28 AM, Magnus Westerlund wrote:
> a) MUST be sent as Individual flows for each component.
>
> b) MUST be multiplexed into a single transport flow.
>
> c) SHOULD be multiplexed into a single transport flow, but the RTCWEB
> peer MUST be able to send them as individual flows.
>
> I would love if people can indicate their choice or preferences.

C. But I'm not sure that the "must" needs to be anything more than "you 
just make two peer connection objects, one for each". (In other words, 
any API that allows for multiplexing almost certainly allows for 
non-multiplexing)... this assumes that the multiplexing is implicit, of 
course. With explicit multiplexing it is even harder... the API needs to 
support turning on and off the multiplexing shim as well, something I'm 
not in favor of.

Matthew Kaufman