Re: [rrg] Host changes vs. network changes

"Joel M. Halpern" <> Sun, 13 December 2009 18:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4CE193A6857 for <>; Sun, 13 Dec 2009 10:06:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.414
X-Spam-Status: No, score=-3.414 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id QgSIP+x9zxV5 for <>; Sun, 13 Dec 2009 10:06:35 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 603503A67E5 for <>; Sun, 13 Dec 2009 10:06:35 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 01D3E4304B5 for <>; Sun, 13 Dec 2009 10:06:23 -0800 (PST)
X-Virus-Scanned: Debian amavisd-new at
Received: from [] ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTP id 7E8A94304AE for <>; Sun, 13 Dec 2009 10:06:22 -0800 (PST)
Message-ID: <>
Date: Sun, 13 Dec 2009 13:06:23 -0500
From: "Joel M. Halpern" <>
User-Agent: Thunderbird (Windows/20090812)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [rrg] Host changes vs. network changes
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IRTF Routing Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 13 Dec 2009 18:06:36 -0000

I try to be very careful when telling other folks (in this case the 
transport and application folks) what they want.

While the multi-path TCP is definitely of particular interest to hosts 
with direct connections to disparate networks, I do not think that is 
the only place it is of interest.  Various companies have made 
significant businesses out of the differences in connectivity in the 
wired networks.  And letting multi-path TCP use multiple of such paths 
seems to actually make the clients more cooperative with the network, 
while getting them better performance.

Hence, I am concerned that we are hiding the current target of interest 
from the folks whoa are interested.  Should they care?  I am certainly 
not in a position to say no.  It is possible that this is essentially 
equivalent to the necessary tradeoffs for aggregation, where the routers 
in the inter-domain sense do not have visibility to all of the details 
(caveat Nimrod, and being able to guess when one needs the details, but 
that is a different debate.)  But it does not appear to be the same 
level of mandatory trade-off that is implicit in aggregation.


Scott Brim wrote:
> 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
> _______________________________________________
> rrg mailing list