Subject: Re: [tcpm] "TCP Multipath" with shim6

From: Joe Touch <[email-masked]>
Date: Tue, 04 Apr 2006 15:34:50 -0700

Scott Leibrand wrote:
> On 03/31/06 at 2:41pm -0800, Joe Touch <[email-masked]> wrote:
> 
>> Scott Leibrand wrote:
>>> Wouldn't it also be a way to get around the shortcoming that most
>>> operating systems don't support SCTP?  Of course, most TCP/IP stacks don't
>>> support shim6 either, so we'll have to see which gets widespread support
>>> (particularly in Windows) first...
>> That's the problem. You can't address the lack of SCTP deployment by
>> introducing a new lack of TCP-multipath deployment ;-)
> 
> More precisely, the lack of shim6 deployment.  Because if the recipient
> doesn't support TCP-multipath, that's OK.  He can still *receive*
> multipath (and not even know it, except that "it's faster") if he supports
> shim6. 

Or things might silently break, e.g., if his receive side requires
strict multihoming.

> As a new layer 3 protocol, shim6 adoption may be easier than
> getting enough applications changed to call SCTP instead of TCP to make a
> difference.

L3 changes could be a LOT harder to deploy; L4 are at least supposed to
be limited to the endpoints.

>> Alternately, just call SCTP "TCP-multipath" and you're basically done,
>> right?
> 
> No, because for that to work, both sides have to use SCTP *instead* of
> TCP.  For TCP+shim6 multipath, OS's just have to be updated to be shim6
> compatible. 

Updating the OS with shim6 is as easy as updating it with SCTP; having
SCTP be the default with fallback seems simple enough (and someone else
noted it had been implemented).

> IMO it's easier to add shim6 to a TCP/IP stack, and just have
> it sitting there ready to spring into action upon receipt of a shim6 I1
> message, than to try to convince every application developer out there of
> the benefits to rewriting their application (or the socket calls) to try
> SCTP first, and if that fails try TCP.

If the socket is what's modified, it's transparent to the app.

...
>> The big question is how many
>> solutions do we need or want?
> 
> Well, the reason we need or want multiple solutions is not so that they'll
> all get implemented on your grandmother's PC, but rather so that they can
> compete for early adopters, and you have a greater likelihood that at
> least one of them might prove useful enough to get widespread adoption.
> Put another way, different protocols were designed for different niche
> uses, and while they may be architecturally similar, in the real world of
> getting them to work well enough for people to actually use them, the fact
> that they operate at different layers, or have other subtle differences,
> can be the difference between viable for widespread use and a niche
> protocol which can never improve the Internet experience for your grandma
> (or your precocious nephew with a server farm in his basement).

A man with one clock always knows what time it is; a man with two is
never sure. Right now (with apologies to Maslow) we have a handful of
clocks wandering around looking for the nail.

Joe

_______________________________________________
tcpm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tcpm

---

From: Janardhan Iyengar <[email-masked]>
Date: Mon, 10 Apr 2006 22:56:45 -0400 (EDT)

Scott,

Sorry about the delayed response.

You are already aware of our work, so let me just point you to specific 
papers:
http://www.cis.udel.edu/~iyengar/publications/iyengar.ToN.pdf
http://www.cis.udel.edu/~iyengar/publications/rbufJournal.pdf

For more info:
http://www.cis.udel.edu/~iyengar/dissertation/

> Do you know if support for multipath SCTP can be implemented independently
> on the sender side without support from the receiver side?  (If you don't

Absolutely yes.

regards,
- jana

--------------------
Janardhan R. Iyengar
http://www.cis.udel.edu/~iyengar
Protocol Engineering Lab, University of Delaware