Subject: Re: SCTP congestion control questions

From: Mark Allman <[email-masked]>
Date: Tue, 06 Feb 2001 09:17:05 -0500

> One important note on this is the stack should avoid sending a
> burst of traffic in retransmission, even it ignores cwnd and rwnd.
> For example, in TCP, SACK info can tell the stack that more than
> half of the window's data is lost (only the last 3 segments are
> received).  The stack should not fast retransmit the whole half
> window at once.

Definatly!

> I remember (I may be mistaken) that the original new Reno which is
> based on the work by J. Hoe, the stack uses something similar to
> "slow start" in the fast retransmit phase to recover more than 1
> lost segment in 1 RTT.

As I remember it, SCTP uses SACK by default and therefore doesn't
really have a newreno-like mechanism.

> Anyway, when the spec is not clear, the implementor should use a
> good judgement on how the SCTP fast retransmit behavior should be
> like.  I believe there is enough info on all those RFCs which can
> be used to make a good decision.

Agreed.

allman

---
Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/

---

From: "Rob + Helena" <[email-masked]>
Date: Wed, 7 Feb 2001 09:31:41 -0000

----------
> From: Kacheong Poon <[email-masked]>
> 
> > 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.
> 
> 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?

OK. However I would suggest that the current SCTP spec should include
at least a statement that this is a problem that implementations SHOULD
avoid and perhaps an implementation note giving references to
research or other IETF work which has possible solutions.
> 
> > 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).
> 
> 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...

Agreed for the TCP case. For SCTP there is a new generation of 
implementors/vendors who may not be aware of the full gamut of
TCP research. Also the subtle differences between SCTP CC
and TCP CC can make it hard to see exactly which research is relevant.
This is why I think it would be good to point out the problem in the
current SCTP specification. 

rgds
rob