Subject: Re: SCTP congestion control questions

From: "Rob + Helena" <[email-masked]>
Date: Wed, 7 Feb 2001 00:15:47 -0000

Hi all

----------
> From: Randall R. Stewart <[email-masked]>
> 
> Mark/Joe:
> 
> One thing to remember on this "burst" is the
> fact that this all supposedly occurs (if I remember
> right from reading Rob's work... Rob help my
> feeble overloaded mind here :->) .. is it
> occurs in one RTT. So, thinking on it, none
> of the reductions  may have taken place.. but of
> course you would have to have a very strange occurance
> in that 
> 
> A) The application would not have more data to clock
>    out (as you point out Mark).
> 
> and
> 
> B) Just has the FR's ACK arrives the application would
>    have to have this "Burst" of new data. 
> 
> These two things seem to me to be unlikely but I don't
> see how other than by having a maxBurst you can gate
> this strange behavior....

If anyone is interested I have put a figure illustrating a
SCTP burst after recovery at:
http://www.teltec.dcu.ie/~brennanr/sctp.html
This comes from my simulation model of SCTP running
over a long delay/high bandwidth link with a droptail
gateway with short qs.

I think that Randal is correct about the non-decay of cwnd
as in the figure we are sending at least 1 pkt per rtt (in fact the
decay is linked to rto rather than rtt directly and these may be
different after a loss).

On the topic of clocking out more data during recovery:
Note that when FR retransmission occurs there is already
a window of data in flight. This is all out of order so is buffered
at the receiver => a_rwnd is reduced to 0. This means that the
sender is rwnd rather than cwnd limited. When the SACK for
the FR'd pkt arrives the q'd data hasn't yet been sent to the
application so a_rwnd is still 0. No data is in flight so the sender
can then send just one more packet. the SACK for this has a_rwnd
= window size. When the receiver gets this it is no longer rwnd
limited => it can send up to cwnd of data. Cwnd was set to half
of the max window when the FR occured => 1/2 a window of
data is sent.

rgds
rob

---

From: "Randall R. Stewart" <[email-masked]>
Date: Wed, 07 Feb 2001 07:04:22 -0600

> Hi all
Rob:

I think this is very similar to what Kevin and Sally discuss in
"Simulation-based Comparisons of Tahoe,Reno and SACK TCP".
In this paper they mention sticking a "maxBurst" on SACK TCP
to prevent this behaivor...

I think this provides the needed safety value for the obscure
places that you will get these results.. In general the
normal mechanisms that Mark and I have discussed will address
these problems....

If someone else has a better suggestion I would be glad to
hear it :) Mark... any ideas?

R

-- 
Randall R. Stewart
[email-masked] or [email-masked]
815-342-5222 (cell) 815-477-2127 (work)