North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: multi-homing fixes

  • From: Joel Baker
  • Date: Sat Sep 01 12:05:57 2001

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.


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 -
[email protected]