From owner-freebsd-net Fri Nov 2 15:42:50 2001 Delivered-To: freebsd-net@freebsd.org Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by hub.freebsd.org (Postfix) with ESMTP id BB4E937B40D for ; Fri, 2 Nov 2001 15:42:42 -0800 (PST) Received: from isi.edu (sci.isi.edu [128.9.160.93]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id fA2NgZO07336; Fri, 2 Nov 2001 15:42:35 -0800 (PST) Message-ID: <3BE32F6A.7060807@isi.edu> Date: Fri, 02 Nov 2001 15:42:34 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Randall Stewart Cc: Lars Eggert , Barney Wolff , freebsd-net@FreeBSD.ORG, xbone@ISI.EDU Subject: Re: SCTP and multiple default routes 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> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org 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