On Tue, Mar 17, 2009 at 10:57 PM, Scott Brim <[email protected]> wrote: > Excerpts from Noel Chiappa on Tue, Mar 17, 2009 01:57:50PM -0400: >> <Apologies for the slow reply - been diverted to other stuff...>
>> > Endpoints need to be able to use multiple attachments and >> > change their attachment points at will. They need identifiers >> > that support that. They can use either higher layer >> > identifiers (e.g. Trilogy multipath) or lower layer ones >> > (MIP, HIP) that decouple the usual tuple from actual >> > addresses. >> >> If the rules of the game are that one can modify hosts, > > One must. I agree here with Scott > >> a whole new world opens. However, the ability to talk to unmodified >> devices may be impacted. > > Try to tune in on a discussion Iljitsch will be leading in TSVarea on > Wednesday: > > 1320-1350 Multipath TCP Opportunities and Pitfalls > Iljitsch van Beijnum > > About the advantages we can gain from making TCP work over > multiple paths, and the issues that need to be solved in > order to make it work. This includes discussion about a > multipath TCP that is supported on both ends and a > multipath TCP that is implemented in just the sender and > works with unmodified receivers. > >> And if one is allowed to modify hosts, on can do all sorts of >> interesting extra capabilities with map-and-encapsulate systems like >> LISP.... > > True. We should compare LISP-in-the-host with other > things-in-the-host. > By adding features to the current stack that will solve something for the enterprises will make it attractive for them to apply an upgrade. Enterprises are struggling today with slow performance of TCP and UDP over long distances, if that can be solved the upgrade of hosts will happen because the enterprises can actually consolidate even more their data centers (and hence save money). But if the stack will only save the Internet then nobody is interested to upgrade the hosts, there has been too much cried wolf about the collapse of Internet and exhaust of IPv4 addresses. Also the new stack must be compatible with the current IPv4 stack - no dual stack with a totally new protocol in parallel - the new stack must be backward compatible adding new extensions that solves issues for both service providers and enterprises. Not all hosts will be upgraded and either every host must be upgraded if the new stack is backward compatible. IEEE and the switching guys have succeeded with that, a 10 Mbps half-duplex Ethernet is a quite different thing from a 10 Gbps full-duplex jumbo and FCoE enabled Ethernet - I believe the similar can be done with IPv4 -- patte _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
