Re: [rrg] Host changes vs. network changes

Scott Brim <sbrim@cisco.com> Tue, 08 December 2009 18:25 UTC

Return-Path: <sbrim@cisco.com>
X-Original-To: rrg@core3.amsl.com
Delivered-To: rrg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3B8A3A6A35 for <rrg@core3.amsl.com>; Tue, 8 Dec 2009 10:25:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7G7cz9GcUADE for <rrg@core3.amsl.com>; Tue, 8 Dec 2009 10:25:54 -0800 (PST)
Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id E04563A691E for <rrg@irtf.org>; Tue, 8 Dec 2009 10:25:53 -0800 (PST)
Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ag4JAH8pHkurRN+K/2dsb2JhbACBTJctqS2XIII7gXcE
X-IronPort-AV: E=Sophos;i="4.47,363,1257120000"; d="scan'208";a="227762785"
Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-2.cisco.com with ESMTP; 08 Dec 2009 18:25:43 +0000
Received: from sbrim-mbp.local (rtp-vpn3-1603.cisco.com [10.82.222.74]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id nB8IPgp8007961 for <rrg@irtf.org>; Tue, 8 Dec 2009 18:25:43 GMT
Message-ID: <4B1E9A26.9060402@cisco.com>
Date: Tue, 08 Dec 2009 13:25:42 -0500
From: Scott Brim <sbrim@cisco.com>
Organization: Cisco Systems, Inc.
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: rrg@irtf.org
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Sun, 13 Dec 2009 09:10:54 -0800
Subject: Re: [rrg] Host changes vs. network changes
X-BeenThere: rrg@irtf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IRTF Routing Research Group <rrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/listinfo/rrg>, <mailto:rrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/rrg>
List-Post: <mailto:rrg@irtf.org>
List-Help: <mailto:rrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/rrg>, <mailto:rrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Dec 2009 18:25:54 -0000

Excerpts from Joel M. Halpern on Mon, Dec 07, 2009 03:11:45PM -0500:
> I like the picture painted below of synergistic, incremental,
> flexbile deployment of improved behavior.
> 
> However, this two-ended incentive relates to one of the things that
> concerns me about the current paths of this work.
> 
> On the one hand, we are looking at a variety of tunneling mechanisms

nit: encapsulation mechanisms, not necessarily "tunneling"

> designed to relive the PI pressure on the core.  One of the other
> important goals of most of these proposals is that they remove the
> difficulty of multihoming and changing providers (thus providing an
> incentive for enterprise cooperation / deployment.)
> 
> Meanwhile, other sides of our house are looking at interesting ideas
> such as TCP Multipath support.  These techniques work most simply
> when the tcp sender and receiver have visibility to the attachment
> addresses of the site to the Internet, and the ability to select
> which one is used.  All of the network based tunneling techniques I
> can see seem to have the property that in providing for multihoming
> and the ability to change providers, they remove exactly the
> visibility that our other hand is trying to utilize.

Can future routing and addressing scaling can be easily engineered in a
way that also allows endpoints easy control over what they want?

I think the situation is not as bad as it seems from your portrayal.
What endpoints want is essentially: control over cost, robustness of
connectivity, and good throughput, and IMHO the most urgent scenario for
multipath is when there are significant differences in access network
behavior -- when the endpoint itself is connected to multiple networks.
 The situation you're describing, where the access network itself is
multiply connected, is important to be able to multipath in, but not
urgent, and ideas are being tossed around about choosing exit points
through collaboration between the endpoint and the network, etc.  In an
encapsulated world an endpoint would be able to choose the exit path
from its provider but not the entry point into its correspondent's
provider.  That may be tolerable.  So if there is a problem, it may not
be serious.

Scott