Subject: Re: [rrg] Host changes vs. network changes

From: Scott Brim <[email-masked]>
Date: Tue, 08 Dec 2009 13:25:42 -0500

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 13 Dec 2009 13:06:23 -0500

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.

yours,
Joel

Scott Brim wrote:
...
> _______________________________________________
> rrg mailing list
> [email-masked]
> http://www.irtf.org/mailman/listinfo/rrg
>