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:
...
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
rrg@irtf.org
http://www.irtf.org/mailman/listinfo/rrg
_______________________________________________
rrg mailing list
rrg@irtf.org
http://www.irtf.org/mailman/listinfo/rrg
