Subject: Re: SCTP congestion control questions

From: "Rob + Helena" <[email-masked]>
Date: Tue, 6 Feb 2001 23:30:14 -0000

Hi All

----------
> From: Mark Allman <[email-masked]>
> 
> > The root cause is that bursting is the result of implementation
> > decisions that are not otherwise prohibited by the protocol.
> 
> Right.  Why not fix these bad decisions?  (Yes, there is a good
> chance this is simply philosophical).

I'm not sure what you are implying here, that implementors should
fix their code or that we should fix the spec.

As a relative newcomer to TCP/SCTP congestion control, my (perhaps
naive) opinion is:
if the protocol specification is sufficiently loose that a problem like
bursts
can occur with poor "implementation decisions" then we should develop
a minimally intrusive fix to the protocol specification that prevents this
behaviour for conformant implementations.

This area of protocol stack development is sufficiently obtuse that
these problems won't become obvious until after deployment (or
at least some very rigourous testing).

rgds
rob

---

From: Kacheong Poon <[email-masked]>
Date: Tue, 6 Feb 2001 17:29:25 -0800 (PST)

> behaviour for conformant implementations.

I share your concern as an implementor.  But sometimes, IMHO BTW, that
there is a gray area.  In this particular case, I believe an implementation
can have several ways to avoid the problem.  And any of those ways will
not cause interoperability problem.  So should a solution be specified in the
protocol as long as the problem is clearly specified?  Or should this be an
implementation choice?

> at least some very rigourous testing).

Again in this particular case, this is a well known problem such that
most, if not all, TCP stacks out there have some form of remedy.  So 
people implementing SCTP should learn from past experience of TCP.  I agree
that there can be other problems which will not be found without rigorous
testing.  This is a reason why some people think that a transport protocol
needs several years of real life experience to be called stable...

							K. Poon.
							[email-masked]