Subject: Re: SCTP congestion control questions

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

> A) Yes you should start sending new data (if you have more data
>    to send of course) 1/2 window later..

Right.

> B) I believe the effect of RFC2861 is already present (at least
>    in theory). If you do NOT start sending new data, you will
>    by definition be "idle", and if you are idle you are to
>    begin halving your cwnd value... 

OK.  

> Another thing we could do just to be a bit cautious is to do what
> Kevin/Sally suggestin "Simulation-based Comparisons of Tahoe, Reno
> and SACK TCP" .. i.e. have a "maxBurst" value that will apply
> after a FR has been acked. This would in theory never be a problem
> if A and B are working... so it would be harmless to add it in as
> a safety measure... I have done so in the next release of the
> ref-implementation :)

I have never been convinced that I should be a huge fan of such
blanket mechanisms.  My hit is that if there is a situation that
causes these bursts, we should fix the root cause.

allman

---

From: Joe Touch <[email-masked]>
Date: Tue, 06 Feb 2001 10:33:13 -0800

> causes these bursts, we should fix the root cause.

The root cause is that bursting is the result of implementation 
decisions that are not otherwise prohibited
by the protocol.

Using Sally's "don't overspecify", the goal of Burst-or-lose
was to put exactly enough protocol mechanism in place to 
prevent accumulation of 'permission to send', which is otherwise
not prohibited by the protocol.

Joe