Date: Fri, 02 Nov 2001 15:42:34 -0800 From: Joe Touch <touch@ISI.EDU> To: Randall Stewart <randall@stewart.chicago.il.us> Cc: Lars Eggert <larse@ISI.EDU>, Barney Wolff <barney@databus.com>, freebsd-net@FreeBSD.ORG, xbone@ISI.EDU Subject: Re: SCTP and multiple default routes Message-ID: <3BE32F6A.7060807@isi.edu> References: <3BE30097.C02C828D@stewart.chicago.il.us> <3BE303EA.1040506@isi.edu> <20011102162701.A38190@tp.databus.com> <3BE317B8.3040108@isi.edu> <3BE32DCC.22A84E28@stewart.chicago.il.us>
next in thread | previous in thread | raw e-mail | index | archive | help
Randall Stewart wrote: > Lars: > > I will add my 2cents to Barney's reply to this as > well.. > > Lars Eggert wrote: > >>Barney Wolff wrote: >> >> >>>Whether or not multiple default routes is a good idea, SCTP-style >>>multihoming makes a tremendous difference for small organizations >>>that cannot justify getting a block of addresses big enough to be >>>routed by multiple providers. With SCTP I can have a host with >>>an address from a cable-modem provider and another from a dsl provider >>>and my peers can treat both as addresses of my one machine, so >>>connections will not break if one link goes down. The big payoff >>>for the Internet as a whole is I don't need a separate route to me >>>in the global routing tables. >>> >>The big drawback is that it requires a completely new protocol... >> > > Which is currently beginning to be deployed. Sun, Aix, Linux and > other O/S's which I refuse to name are putting forward SCTP.. That's an OS; deployment implies that the applications _AND_ libraries are also all changed, and that the users select them. >>It also requires both peers to speak SCTP, and applications in question >> >>must be changed to run over SCTP as well. In other words, it doesn't >> > > The change is a very very simple one instead of > > fd = socket(AF_INET,SOCK_STREAM, IPPROTO_TCP); > > you od > > fd = socket(AF_INET,SOCK_STREAM, IPPROTO_SCTP); > > Not a big deal for the TCP compatibility model. You don't > get to use streams if you do the above only .. but hey you > get the multiple interface... Not a big deal... Presuming you have source code for every application you want to modify. PS - how many of TCP's options translate to SCTP options directly? E.g., Nagle, etc.? All of those must be converted as well. >>work yet, and it will be some time before it does, and then only for modified apps. >> > > Not as long as you think.. IMHO I'll make that bet. What will apps do - use TCP some times, and SCTP others? Will each application have two versions? A configuration that lets you select? Ever seen this happen before? How many current apps. have this capability (e.g., to use two different protocols)? >>>I would gladly pay for two such links if there were an automatic way >>>to switch away from a broken link. Without asking cable or dsl >>>providers to talk bgp to me (which they will surely refuse to do) >>>this is not easy. >>> >>You can get the exact same behavior toady, with existing Internet >>protocols: Create an IP tunnel to the peer over one interface pair, >>switch the tunnel over to the other pair in case of failure. This is >>transparent to the application (it uses the virtual addresses of the >>tunnel), uses existing protocols (TCP/UDP over IP in IP), works now. >> >>Only new piece is reconfiguring your tunnel, which is trivial (one or >>two system commands, and can be easily automated.) > > And to add to Barney's issue... you also must wait for a > routing convergence to know to move the tunnel. In the case > of SCTP the first timeout moves you to the alternate. The 'routing convergence' can happen at the layer of the tunnels, e.g., at the response time of a round trip + the routing protocol's one-hop update frequency. Joe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3BE32F6A.7060807>