Subject: [rddp] 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/
 > 

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