Subject: Re: [Tsvwg] Re: "DO IT RIGHT", or "DON'T DO IT AT ALL" (fwd)

From: Sam Liang <[email-masked]>
Date: Fri, 13 Dec 2002 21:25:44 -0800 (PST)

By mistake, I didn't cc the following reply to Mark's email to the mailing
list.  Here you go.  -- Sam

   My problem with SCTP is that there is no major application that is dying
 for its features.  Maybe there is some applications that may work a little
 better with some functionalities SCTP provides, but that's not a valid
 motivation to start from scratch to reinvent everything TCP already
 does and then adds a couple of new features.
 
   Should we create a new protocol whenever we want to do something a bit
 new?  There are many ways to meet new requirements, inventing a new
 protocol is not necessary the right one, especially when the current
 protocol works pretty well.

 > 
 > > Sam Liang wrote:
 > >   It sounds like that eventually we'll all migrate to SCTP.  Maybe
 > > SCTP can do a couple things TCP doesn't do currently. But when TCP
 > > can already do 95% of the job, what's the compelling reason for
 > > everybody to move to SCTP?
 > > 
 > >   To me, for the really appealling functionalities, we can extend
 > > TCP to support them. It's much more deployable than attempting to
 > > implement a brand new protocol, which basically does the same
 > > thing as TCP except for being much more cumbersome, in every
 > > operating system. There is no need to reinvent the wheel, when the
 > > current wheel rolls fine.
 > 
 > I am pretty much done arguing this point on the mailing lists.  But,
 > you have laid-out one approach to protocol development and
 > evolution, so allow me a couple of paragraphs to give the flip
 > side.
 > 
 > You have sort of hit the crux of the problem.  In theory, TCP can do
 > everything anyone would want a transport protocol to do
 > (out-of-order delivery, partial reliability, unreliable, VJCC,
 > TFRC-CC, byte-based, record-based, whatever).  We can add tricks and
 > use reserved bits and add options and etc.  In addition, looking at
 > any given problem it is nearly always easier to extend the known,
 > widely deployed thing than it is to start fresh.  But, while that is
 > the short-term path of least resistence, it is not always the wisest
 > approach.  It leads to huge, bloated Do Everything protocols that

  Isn't SCTP such a  "hugh, bloated Do Everything protocol"?

 Sam

 > are extremely difficult to implement properly, monitor, program for,
 > etc.  E.g., we could have hacked on TCP a lot instead of writing
 > SCTP.
 > 
 > There is much about SCTP that I do not particularly care for.
 > However, I think it is a nice step.  It is another tool in our
 > protocol toolbox.  And, if that tool happens to be better than the
 > other tool in the space (TCP) then we should use it.  And, I have
 > not heard much compelling argument that SCTP is not a better fit in
 > this case.  
 > 
 > Finally, the more people use this new tool the better it will
 > become.  If we continually push it off as "it's not baked yet, so we
 > need to hack around it using the old tool" then the new tool will
 > never be baked enough.
 > 
 > allman
 > 
 > 
 > --
 > Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/
 > 

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sat, 14 Dec 2002 00:52:32 -0700

Sam,

>  protocol works pretty well.

  ;)

Are you saying that many engineers wasted the last 3 or 4 years of their
lives, even paid by their employers to do so, in developing RFC 2960?
(Many of them the last thing they did before their pink slip?)

Ever hear of SIGTRAN?  Ever hear of RT-CORBA?  Ever hear of IPS?  Gee, ever
hear of SIP?  Ever hear of MEGACO?  Ever hear of RDDP?  Ever hear of RSERPOOL?

Ever hear of the USAF?

No applications -- humbug! -- SCTPs problem might be that it has too many
applications demanding it.

Where have you been?  The Twilight Zone?

(Oh, I see: Stanford; so you don't know what's happening at Temple University,
the University of Delaware, the University of Essen, ...).

  ;)

--brian

-- 
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
[email-masked]    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
                        ¦ Therefore  all  progress  depends on the ¦
                        ¦ unreasonable man. -- George Bernard Shaw ¦
_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: Sam Liang <[email-masked]>
Date: Sat, 14 Dec 2002 01:20:46 -0800 (PST)

> (Many of them the last thing they did before their pink slip?)

  I respect the intellectual effort, and I think it probably helps us
understand many issues better.  However, although it may be a worthwhile
academic research project, it doesn't mean it's necessarily a practical
approach, and I don't see how SCTP is taking over the world.

  As Joe noted earlier in the thread, ATM attracted tremendous attension a
few years back and it was claiming to take over the world. But you don't
hear all that any more and what's the most popular today are IP and Ethernet.

> hear of SIP?  Ever hear of MEGACO?  Ever hear of RDDP?  Ever hear of

  Do they have to use SCTP or die?

  As I see it, all of these can be supported by TCP or a slight extension
to TCP. 

> Where have you been?  The Twilight Zone?

  So all the people who fail to jump on the SCTP bandwagon are in the
Twilight Zone?

Sam

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sat, 14 Dec 2002 12:22:40 -0700

Sam,

>   As I see it, all of these can be supported by TCP or a slight extension

Please, come over to the SIGTRAN WG list and explain how TCP can be
used and SCTP is not necessary.

--brian