|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: multi-homing fixes
On Sat, Sep 01, 2001 at 10:59:24AM +0200, Iljitsch van Beijnum wrote: > > On Fri, 31 Aug 2001, Greg Maxwell wrote: > > > > addresses, so when one path goes down, it will use another. (SCTP is > > > useless as a TCP replacement, though.) And there have been successful > > > I've been being good about keeping my multi6 advocacy off of nanog, but I > > have to correct here: SCTP can be used as a full replacement of TCP as it > > is a strict superset, it also can replace UDP for many applications. > > That is like replacing passenger trains by freight trains. After all, > aren't passengers just one type of freight? > > SCTP has a whole bunch of features that are of no use to our current > applications, that all expect TCP. It would be very unwise to switch to a > new transport protocol just because it has one desirable feature that can > very easily be built in TCP. > > Two modules that do 99% the same thing but with different code is bad > software design. And SCTP is not backwards compatible with older TCP > implementations or access filters or firewalls or anything. s/TCP/IPv4/ s/SCTP/IPv6/ Interesting to read that way... and it explains why SCTP isn't even known to most of the folks I deal with on a daily basis, much less in any sort of wide deployment. Me, I prefer to build a new car that's fully up to new design specs, rather than try to retrofit rocket boosters onto the old Studebaker. This isn't to claim, in any way, that "TCP is dead", mind you; but SCTP answers a fairly fundamental set of problems, with a different set of design goals than TCP and UDP were written for. Trying to mangle TCP to accomodate those goals seems likely to produce more confusion than viable code. BTW, SCTP is just as compatible with filters and firewalls as any other IP based protocol. It has a protocol number and a public design spec. That few of these implement the more advanced matching sets that can be used for TCP is largely due to the catch-22 of router vendors not wanting to waste time on writing code for it until people demand it, and people not demanding it because said vendors don't support it, so how big can it really be? (Oh, and on a sidenote: my Linux firewall will filter it just fine, without even knowing what it is). In any case. I agree with your assertion that TCP could be rewritten to do the same thing as SCTP. I assert, in turn, that you would end up re-writing most of the SCTP spec in the process, and have an equal amount of new (read 'buggy') code. As for the 'SCTP isn't backwards compatible with older TCP' claim... uhm, TCP isn't backwards compatible with UDP, either. Your point? -- *************************************************************************** Joel Baker System Administrator - lightbearer.com [email protected] http://www.lightbearer.com/~lucifer
|