Re: [rrg] Host changes vs. network changes

HeinerHummel@aol.com Sun, 06 December 2009 09:12 UTC

Return-Path: <HeinerHummel@aol.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 B5BB43A682C for <rrg@core3.amsl.com>; Sun, 6 Dec 2009 01:12:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.207
X-Spam-Level:
X-Spam-Status: No, score=-2.207 tagged_above=-999 required=5 tests=[AWL=0.391, BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 TOjc172WENq3 for <rrg@core3.amsl.com>; Sun, 6 Dec 2009 01:12:28 -0800 (PST)
Received: from imr-mb01.mx.aol.com (imr-mb01.mx.aol.com [64.12.207.164]) by core3.amsl.com (Postfix) with ESMTP id 518153A635F for <rrg@irtf.org>; Sun, 6 Dec 2009 01:12:27 -0800 (PST)
Received: from imo-ma04.mx.aol.com (imo-ma04.mx.aol.com [64.12.78.139]) by imr-mb01.mx.aol.com (8.14.1/8.14.1) with ESMTP id nB69C6KB000758; Sun, 6 Dec 2009 04:12:06 -0500
Received: from HeinerHummel@aol.com by imo-ma04.mx.aol.com (mail_out_v42.5.) id t.d5c.53588e25 (32915); Sun, 6 Dec 2009 04:12:02 -0500 (EST)
From: HeinerHummel@aol.com
Message-ID: <d5c.53588e25.384ccf61@aol.com>
Date: Sun, 06 Dec 2009 04:12:01 -0500
To: christian.vogt@ericsson.com, jnc@mercury.lcs.mit.edu
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="-----------------------------1260090721"
X-Mailer: 9.0 SE for Windows sub 5021
X-AOL-SENDER: HeinerHummel@aol.com
Cc: rrg@irtf.org
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: Sun, 06 Dec 2009 09:12:29 -0000

 
Christian,
No question, network related objectives may either be accomplished by  
network- or host-based solutions.
The speed of introduction is hereby an interesting aspect.
Furthermore each way has its pros and cons.
Example: Handling of network congestions. Host-based: The sender can slow  
down the transmission rate (i.e. the service becomes worse). And host-based  
Multihoming is not a big help unless the  ingress router
of the preferred "home" is part of the congested area.
Whereas a network-based solution could detour the congested area (given  
that there is a smarter routing technology as of today).
 
Heiner
 
 
 
In einer eMail vom 06.12.2009 07:07:50 Westeuropäische Normalzeit schreibt  
christian.vogt@ericsson.com:

On Dec  1, 2009, Noel Chiappa wrote:

> When it comes to preferring  network-based or host-based solutions, when
> considering  _architectural_ factors, I actually prefer the latter
> (because I want  to move functionality out of the network, to maximize
> long-term  flexibility). However, _engineering_ factors (e.g. the
> difficulty of  changing hosts) has long led me to conclude that _initial_
> deployment  has to be network-based.

We often take it that host changes are harder  than network changes.  But
is this assumption actually valid?   There is, in fact, substantial
evidence that it is not.  Consider IP  version 6, which was deployed in
operating systems well before operators  deployed it in their networks.

Also from an economic standpoint, host  changes appear easier than
network changes:  Given the small number of  operating systems used by
the majority of hosts, and given the highly  automated methods to update
these operating systems, changes to one of the  main operating systems
quickly affect a large number of hosts, hence at a  small cost per host.
Network upgrades are slower and more  expensive.

Furthermore, for the same reason that network operators  would tend to
defer changes, operating system vendors may be eager to adopt  them. This
happens when the change must be bilateral to yield a benefit --  as is
the case with multi-homing support, which we are discussing  here.
Network operators gain no immediate benefit by adopting a  network-based
multi-homing mechanism early on, because the remote part of  the
mechanism does not exist initially.  Operating system vendors, on  the
contrary, can distinguish their product from competition based on  the
new multi-homing support, as the multi-homing support  improves
communications between their operating system relative to the  operating
systems without multi-homing support.

Thus, in my personal  opinion, host-based multi-homing support will have 
a faster impact than  any corresponding network-based support.

-  Christian


_______________________________________________
rrg  mailing  list
rrg@irtf.org
http://www.irtf.org/mailman/listinfo/rrg