Re: [rtcweb] To multiplex or not!

Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com> Wed, 20 July 2011 09:37 UTC

Return-Path: <stefan.lk.hakansson@ericsson.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 A6DD221F861A for <rtcweb@ietfa.amsl.com>; Wed, 20 Jul 2011 02:37:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.246
X-Spam-Level:
X-Spam-Status: No, score=-6.246 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
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 72S7239BBNBn for <rtcweb@ietfa.amsl.com>; Wed, 20 Jul 2011 02:37:07 -0700 (PDT)
Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 16D3621F85B8 for <rtcweb@ietf.org>; Wed, 20 Jul 2011 02:37:01 -0700 (PDT)
X-AuditID: c1b4fb3d-b7c17ae00000262e-f7-4e26a1bceed4
Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id B9.AA.09774.CB1A62E4; Wed, 20 Jul 2011 11:37:00 +0200 (CEST)
Received: from [150.132.141.68] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.137.0; Wed, 20 Jul 2011 11:37:00 +0200
Message-ID: <4E26A1BB.8020403@ericsson.com>
Date: Wed, 20 Jul 2011 11:36:59 +0200
From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11
MIME-Version: 1.0
To: rtcweb@ietf.org
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: 8bit
X-Brightmail-Tracker: AAAAAA==
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: Wed, 20 Jul 2011 09:37:07 -0000

FWIW I'm in camp A (but of course C is fine as well). Flow based QoS is 
part of modern cellular networks, and I would like rtcweb to work well 
on them (our experience is also that when the throughput is reduced you 
prefer the video to be degraded rather than having the audio being 
chopped - so you would need them to be individual flows).

Stefan
On 2011-07-19 16:28, Magnus Westerlund wrote:
> Hi,
>
> This email is as an individual contributor.
>
> I want to get started on the discussion of the Multiplexing of the
> various protocols over single lower layer transport flow, such as a UDP
> flow. I will attempt to split up the questions into different emails.
>
> The first question I think is reasonably easy to get answered, but I
> think it is time we determine if my belief in the answer is correct or not.
>
> The traffic between two RTCWEB peers from the various components, such
> as RTP sessions, datagram service:
>
> 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.
>
> I personally prefer A as it it is simplest in all aspect except the NAT
> traversal.
> - It allows for flow based QoS.
> - It is the what the implementation that exist mostly do
> - Signaling protocols that exist support it, no extra functionality
> - People are used to the concept
> - It minimizes the difference to legacy.
>
> Thus it is the quickest road to define something with the least formal
> push back and concern over maturity of any solution.
>
> The downside with B and C is that we do have to solve the multiplexing
> and get an agreement that gets through all the hurdles.
>
> Of these two opens I do prefer C.  Although it results in the extra
> complexities of having both alternatives, it will give us both a
> fallback, flow based QoS and better legacy support.
>
> Now it is your time to make your opinion heard!
>
> Cheers
>
> Magnus Westerlund
>
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVM
> ----------------------------------------------------------------------
> Ericsson AB                | Phone  +46 10 7148287
> Färögatan 6                | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
> ----------------------------------------------------------------------
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb