Subject: Re: [Tsvwg] SCTP Max.burst and CWND

From: "Armando L. Caro Jr." <[email-masked]>
Date: Tue, 5 Mar 2002 17:25:17 -0500 (EST)

On Tue, 5 Mar 2002, Mark Allman wrote:
>
> That said, I think 4 is a reasonable number, but I would extend your
> line of thinking a little.  I would use something like this:
>
>   * Assume that outd always has the number of outstanding (sent but
>     not acknowledged) segments.
>
>   * When you leave recovery you compare outd and cwnd.
>
>     if ((outd + 4) < cwnd)
>         cwnd = outd + 4;
>
>   * You leave ssthresh alone.

Looks good to me! So now, Max.Burst is just a parameter to your algorithm,
which in your example is 4.

Also, this algorithm should be applied _all_ the time. Yes, there are only
3 scenarios (that I know of) when bursts are likely:

	1. after FR recovery
	2. after idle periods
	3. sender goes from application-limited to network-limited

Scneario 1 is what we have been discussing. Scenario 2 is already covered
in RFC2960. Scenario 3 is not addressed in RFC2960, but should be. RFC2861
explains how to address the issue in scenario 3... degrade cwnd every rto
that the full cwnd isn't being used. However, since the granularity used
for degradation is an rto, it is possible to get bursts within each rto.
So applying your above algorithm _always_ would be benefical.

~armando

0--                                                --0
| Armando L. Caro Jr.     |       [email-masked] |
| University of Delaware  |  www.cis.udel.edu/~acaro |
0--                                                --0

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

---

From: Mark Allman <[email-masked]>
Date: Tue, 05 Mar 2002 16:07:27 -0500

> Yes, I agree. However, if the sender were to go back to slow
> start, I am sure that many would be concerned that SCTP would act
> too conservatively in comparison to TCP. So I suggest a
> compromise... The sender goes back to slow start with an intial
> cwnd of 4*MTU. In other words, when a SACK arrives which
> acknowledges a fast rtx'd tsn, the following should be done
> (instead of applying Max.Burst):
> 
> 	cwnd = 4 * MTU
> 	ssthresh stays the same

The specific initial value does not matter as much as the notion
that we use cwnd & slow start as the control, to me.  In one of my
emails I think I noted that we may have to invent new ways to
manipulate cwnd -- that's fine.  My only point is lets keep the one
control and not go to two.

    if ((outd + 4) < cwnd)
        cwnd = outd + 4;

First, this says that if we leave recovery and were able to send
stuff during recovery and keep cwnd full then fine -- no adjustment
is needed.  And, it says that if we were not able to keep cwnd full
during recovery we can send 4 segments on top of anything that we
were able to squeeze out during recovery.  This is different than
setting cwnd to a constant.  Say your cwnd is 8 segments, but during
recovery you could only send 3 segments because of the rwnd.  If you
set cwnd to 4 segments when you leave recovery you will only be able
to send 1 segment.  Under the scheme I outlined you can use more of
the cwnd (4 more segments on top of the 3 you already sent) that you
have accumulated -- while limiting the line-rate burst to 4
segments.  Then, we slow start back up to ssthresh.

That seems like an easy and good way to solve this particular
problem in my opinion.

allman

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