Re: [rtcweb] How to multiplex between peers

Cullen Jennings <fluffy@cisco.com> Wed, 20 July 2011 00:43 UTC

Return-Path: <fluffy@cisco.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 11FAD21F85E2 for <rtcweb@ietfa.amsl.com>; Tue, 19 Jul 2011 17:43:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.054
X-Spam-Level:
X-Spam-Status: No, score=-104.054 tagged_above=-999 required=5 tests=[AWL=-1.455, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 59JdUnPsywNY for <rtcweb@ietfa.amsl.com>; Tue, 19 Jul 2011 17:43:39 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 1C5DF21F85B1 for <rtcweb@ietf.org>; Tue, 19 Jul 2011 17:43:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=5126; q=dns/txt; s=iport; t=1311122619; x=1312332219; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=ygHJCXzFogQdk+pTW/INaJGtcePi/uoopo6cNOMcDHE=; b=HUvzF9TyWhqstqKURwB/PnaDjNj3bYtBgMbmBV3Ep7u6a11DhVtZRA83 /UyZSAKl8DV4XDgrpCviuNU2UOCJDi43GFsR7ncVxsSxtMURMwUgmUvxv Oj1HzXy8FPnt7UoV0ocmsY3ld2F96+2y8ksOZf7hUxbaYGWKI6gqOHJi7 k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EABMkJk6rRDoG/2dsb2JhbABGDqdbd4h8pWKeTIMjgjpfBIdUixSFBIt2
X-IronPort-AV: E=Sophos;i="4.67,231,1309737600"; d="scan'208";a="4545046"
Received: from mtv-core-1.cisco.com ([171.68.58.6]) by rcdn-iport-4.cisco.com with ESMTP; 20 Jul 2011 00:43:38 +0000
Received: from [10.21.86.37] ([10.21.86.37]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p6K0hbCN028506; Wed, 20 Jul 2011 00:43:37 GMT
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: Cullen Jennings <fluffy@cisco.com>
In-Reply-To: <4E259EAD.3060505@ericsson.com>
Date: Tue, 19 Jul 2011 17:43:36 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <FAE78F7C-8C51-41C4-B3D7-6497396E12A5@cisco.com>
References: <4E259EAD.3060505@ericsson.com>
To: Magnus Westerlund <magnus.westerlund@ericsson.com>
X-Mailer: Apple Mail (2.1084)
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] How to multiplex between peers
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 00:43:43 -0000

inline ...

On Jul 19, 2011, at 8:11 , Magnus Westerlund wrote:

> WG,
> 
> As individual contributor.
> 
> I would recommend that people read both
> https://datatracker.ietf.org/doc/draft-rosenberg-rtcweb-rtpmux/?include_text=1
> and
> https://datatracker.ietf.org/doc/draft-perkins-rtcweb-rtp-usage/?include_text=1
> before getting into this debate.
> 
> Assuming that the consensus of "To multiplex or not!" thread is either
> of the options requiring multiplexing we get to the question of how to
> do the multiplexing.
> 
> Lets start with a very fundamental question:
> 
> Explicit vs Implicit multiplexing
> 
> So the explicit is when something in the received packets has the
> explicit purpose to identifies a context that resolves the protocol, the
> session context etc.
> 
> Implicit is when we have no such explicit field, instead we have to rely
> on that investigating values of particular bits in the payload of the
> packet. For example trying to identify RTP based on the first byte of
> the RTP header where the version two bits shall be 10b.
> 
> I am strongly arguing against implicit identifying the protocol for the
> following reasons.
> 
> 1. We have 4 or more protocols (The possible set of protocols include:
> STUN, RTP/RTCP, Datagram, and DTLS-SRTP. There is likely future
> extensions, like reliable protocol)  that needs to be identified and
> demultiplexed. A single extension in one of these protocols can cause
> the whole house of cards to come tumbling down.

Uh, we already demux STUN, RTP/RTC, DTLS-SRTP based on first byte and this is no big deal and is sort of water under the bridge at this point. But this first byte multiplex issues is a red herring to this topic, what happens with the demux of these protocols does not really have much to do with how to demux the different RTP sessions. 

> 
> 2. It will require one to find an RTP internal session multiplexing
> mechanism. This is likely not easy or causes a fork of RTP into two
> non-compatible versions. In addition such a mechanism needs defining
> which takes time, likely substantial time as there is quite a lot of RTP
> mechanisms to consider.

A bunch of us our proposing SSRC. We not seeing any problems with it.  I rather having this discussion be concrete around the specific proposal on the table and not just some abstract it might be hard to find something. 

> 
> 3. We likely need a multiplexing layer anyway if we want a fall back
> over WebSockets or HTTP.

Not really - I think this is best done by making another TURN like protocol that is compatible uses WebSockets or HTTP as the underling transport. An architecture like this means that  that protocol is selected unilateral by the endpoint and used to get through that endpoints  firewalls. Both clients don't have to agree to do the same thing - just like If I am using a TURN and you are not, we can still  have a call. Avoid a bilateral solution where possible make it much easier to roll out. 

> 
> Thus we see this a very fragile mechanism that creates additional work
> overhead and large uncertainties in when it would be available.

This all sounds sort of doom and gloom but lets talk about real problems. 

> 
> We have in our draft:
> https://datatracker.ietf.org/doc/draft-perkins-rtcweb-rtp-usage/ looked
> at two possible suggestions for explicit multiplexing. Either a thin
> shim layer primarily consisting of a identifier that through negotiation
> is bound to a context, like an particular RTP session or a datagram
> channel.

The problem with this is that if you are talking to a device that does not support this you forever have to go through some intermediary gateway that strips the byte. Just like turns servers, this reduces the user experience by adding latency and jitter and is expensive to run due to the bandwidth required. 

> 
> The other alternative we considered was using DCCP over UDP for RTP and
> datagram. That way we got a complete port space for multiplexing
> different purposes for flows. We also got a transport framework with its
> own negotiation, congestion control, a several other features.

This has the same problem as above with the added problem of I am not aware of a good (meaning widely tested) DCCP implementation in user land and to be deployable this pretty much needs to be all user land. 

> 
> We invite people to consider these proposals or suggest better
> alternatives of explicit multiplexing. But I hope we can avoid a serious
> mistake and select implicit multiplexing.

I'd like people to start talking about what the actual serious mistakes of implicit multiplexing as specified in the SSRC proposal are. Ok, Have I thrown the gauntlet down enough :-) Really, I'm just not getting what the problems are - if I understood the problems, I might have a different view point on this. 

Cullen <with my individual contributor hat on>