[splices] draft-loreto-splices-disaggregated-media-02: competing protocol analysis

Adam Roach <adam@nostrum.com> Tue, 26 July 2011 18:26 UTC

Return-Path: <adam@nostrum.com>
X-Original-To: splices@ietfa.amsl.com
Delivered-To: splices@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5591E11E8082 for <splices@ietfa.amsl.com>; Tue, 26 Jul 2011 11:26:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.263
X-Spam-Level:
X-Spam-Status: No, score=-102.263 tagged_above=-999 required=5 tests=[AWL=0.337, BAYES_00=-2.599, SPF_PASS=-0.001, 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 DCOrU6BjQmeN for <splices@ietfa.amsl.com>; Tue, 26 Jul 2011 11:26:31 -0700 (PDT)
Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 663465E8001 for <splices@ietf.org>; Tue, 26 Jul 2011 11:26:30 -0700 (PDT)
Received: from dhcp-1418.meeting.ietf.org ([130.129.20.24]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p6QIQNR9030458 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 26 Jul 2011 13:26:24 -0500 (CDT) (envelope-from adam@nostrum.com)
Message-ID: <4E2F06CF.4080403@nostrum.com>
Date: Tue, 26 Jul 2011 14:26:23 -0400
From: Adam Roach <adam@nostrum.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: draft-loreto-splices-disaggregated-media@tools.ietf.org, splices@ietf.org
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: pass (nostrum.com: 130.129.20.24 is authenticated by a trusted mechanism)
Subject: [splices] draft-loreto-splices-disaggregated-media-02: competing protocol analysis
X-BeenThere: splices@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Loosely-coupled SIP Devices \(splices\) working group discussion list" <splices.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/splices>, <mailto:splices-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/splices>
List-Post: <mailto:splices@ietf.org>
List-Help: <mailto:splices-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/splices>, <mailto:splices-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Jul 2011 18:26:32 -0000

Section 4.1.4 of draft-loreto-splices-disaggregated-media-02 currently 
describes a (rather clever) way to move a SIP session from one client in 
a disaggregated system to another, so as to allow the device that owns 
the SIP association with the far-end to be removed from the call.

I like it. It actually does a good job of showing that the system in 
question actually isn't an all-entities-are-equal federation of peer 
devices. In fact, it *does* have a critical central controller of sorts, 
and we need to be able to take steps to move that critical central 
controller functionality around. (This is inherent in any system that 
requires no support from the far end, since someone needs to own the SIP 
session).

However, then we get into section 5. I'm not sure what section 5 is 
trying to talk about, since it discusses a model that is not relevant to 
any of the described solutions. Even the INVOKE-based one being proposed 
by this document.

Even more interestingly, I note that the transfer-of-control approach in 
section 4.1.4 can be applied equally well to any central-control model. 
MBUS, for example. Or MEGACO. So the statement "transferring the SIP 
dialog from a controller to a new one using REFER and Replaces is 
complex and requires support from the far end" isn't really true -- 
everyone can use the section 4.1.4 INVITE/Replaces approach to move 
control around. The INVOKE-based approach described in this document is 
hardly unique in this respect.

On top of this, the analysis in section 3.1.1 and 3.2.1 both have the 
rather gonzo "issue" of "you need to implement the protocol." That's 
true of *any* solution -- INVOKE included -- so it's hardly a 
distinguishing factor. If you want to try to quantify the ease of 
implementation, that might be a useful discussion. But simply saying 
"you have to implement something" is always, always, always true for a 
new mechanism.

So, once you make a more honest analysis of the other protocols, section 
3.1.1 actually ends up looking like this:

    The Mbus protocol introduces the following issue:

    Local network:  Mbus uses multicast with a limited scope for message
       transport.  The multicast limits the coordination mechanism only
       to groups of devices that are connected to a local network.  So
       Mbus can be used in a disaggregated media scenario only if all the
       different devices under the user control, or at least the one the
       user wants to involve in the communication, are attached to the
       same local network.

And section 3.2.1 looks like this:

    The Megaco protocol introduces the following issues:

    None.

/a