Re: [rtcweb] To multiplex or not!

Emil Ivov <emcho@jitsi.org> Wed, 20 July 2011 11:08 UTC

Return-Path: <emil@sip-communicator.org>
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 C932D21F8A66 for <rtcweb@ietfa.amsl.com>; Wed, 20 Jul 2011 04:08:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 yHwsEK1Ykb8D for <rtcweb@ietfa.amsl.com>; Wed, 20 Jul 2011 04:08:54 -0700 (PDT)
Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3DC9821F86A1 for <rtcweb@ietf.org>; Wed, 20 Jul 2011 04:08:54 -0700 (PDT)
Received: by wyj26 with SMTP id 26so94996wyj.31 for <rtcweb@ietf.org>; Wed, 20 Jul 2011 04:08:53 -0700 (PDT)
Received: by 10.216.79.5 with SMTP id h5mr7233021wee.110.1311160132767; Wed, 20 Jul 2011 04:08:52 -0700 (PDT)
Received: from porcinet.u-strasbg.fr ([2001:660:4701:1001:21e:c2ff:fe1b:2fe]) by mx.google.com with ESMTPS id m38sm85405weq.21.2011.07.20.04.08.51 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 20 Jul 2011 04:08:51 -0700 (PDT)
Message-ID: <4E26B742.6050606@jitsi.org>
Date: Wed, 20 Jul 2011 13:08:50 +0200
From: Emil Ivov <emcho@jitsi.org>
Organization: Jitsi
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; bg; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11
MIME-Version: 1.0
To: Cullen Jennings <fluffy@cisco.com>
References: <4E259484.20509@ericsson.com> <37897D97-85A9-4B21-85C3-A7E9BE1EF3E7@cisco.com>
In-Reply-To: <37897D97-85A9-4B21-85C3-A7E9BE1EF3E7@cisco.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
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: Wed, 20 Jul 2011 11:08:59 -0000

На 20.07.11 02:05, Cullen Jennings написа:
> I'd like to see it that devices MUST support multiplexing and I'd
> probably be in favor of also MUST support non multiplexed flows. The
> multiplexing is a big advantage for any device that needs to deal
> with NATs so I suspect many "legacy" devices would be moving to this
> even if there was no need to deal with the browser like devices. I
> also think that allowing this type of multiplexing will make firewall
> traversal easier where a device can configure a firewall to open just
> one specified port and use it for RTP.

I don't really agree with this part. Devices would still need to handle
candidates that come from  STUN, TURN, UPnP, host IPv4, host IPv6, and
potentially VPN, MIPv6 and other tunnelling mechanisms. Whether or not
this only happens for a single component/stream doesn't really simplify
code does it?

According to my personal experience with our work on ice4j.org, managing
multiple checklists was far less resource consuming than implementing
TURN tunnels and persmissions, STUN multiplexing, synchronisation and
even getting pacing right.

<snip>

> The primary reason I want multiplexing is the time to set up all the
> ICE connections. The fact of the matter is that NATs limit how
> quickly you can create new flows. If all you need is something simple
> with just 2 flows, one for audio and one for video, this is workable.
> But as soon as you move to trying to have a transition strategy from
> V4 to V6 and multiple person video or even just multi screen video,
> the user experience goes downhill rapidly.

I agree more with this argument, although freezing candidates
significantly brings down the overhead incurred by having multiple
streams and components and I am not sure that the actual win here would
be good enough to pay for implementing multiplexing and for breaking
interoperability with those that don't have it.

> Much of the IETF thinking around ICE was done on the assumption that
> ICE could be done before ringing started or during ringing but the
> deployments I am seeing are moving more towards not doing ICE until
> after a call is answered. There are many reasons for this but one of
> them is that if Alice calls Bob, and Bob is on a mobile internet
> device, you don't want to reveal Bob's location to Alice before Bob
> even decides to answer the call. Given an IP address more or less
> reveals location these days that a bit of issues to do ICE before
> answering. This puts more pressure on being able to do ICE quickly
> for a good user experience.

Agreed, but is multiplexing the only way of bringing the time down? The
XMPP crowd for example has been using a mechanism that allows candidates
to be sent as they become available rather than wait for all harvesting
to complete. Maybe this is worth exploring and integrating in the
official ICE (although I don't see how it would work with SIP).

Cheers,
Emil

> 
> Cullen <with my individual contributor hat on>
> 
> On Jul 19, 2011, at 7: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
> 
> 
> Cullen Jennings For corporate legal information go to: 
> http://www.cisco.com/web/about/doing_business/legal/cri/index.html
> 
> 
> _______________________________________________ rtcweb mailing list 
> rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
> 

-- 
Emil Ivov, Ph.D.                       67000 Strasbourg,
Project Lead                           France
Jitsi
emcho@jitsi.org                        PHONE: +33.1.77.62.43.30
http://jitsi.org                       FAX:   +33.1.77.62.47.31