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

From: Mark Allman <[email-masked]>
Date: Mon, 04 Mar 2002 07:58:35 -0500

Folks-

The quoting in this thread got a little deep for me, so I am not
sure I caught everything.  However, I'll throw out my opinion --
that maxburst is mostly bogus in my mind.

I mostly don't like it because we currently have a limit on the
amount of data we can inject into the network -- i.e., cwnd.  So,
why do we need another?  It seems to me that adding another control
is just asking for trouble and subtle problems caused by the
interaction between the maxburst value and cwnd.

That is not to say that we might not need new ways to control cwnd.
I think the congestion window validation stuff (RFC 2861) goes a
ways towards solving the problem.  I like the notion in this
document alot, though.  Basically you use your cwnd or you lose it.

There are several instances in which we can burst.  Lets consider a
few that I can think of this early in the morning:

  * We save "permission to send".  Cwnd is supposed to be an
    estimate of the amount of traffic you can inject into the
    network path per RTT.  Let's say that cwnd = N segments.  If you
    are only sending N/2 segments per RTT you have no idea whether N
    is really still the network's limit or not.  So, even with a
    maxburst control you may end up seeing loss when you try to use
    a cwnd of N segments -- if that is, indeed, over the path's
    limit.  Hence, even though maxburst might have saved you from
    doing a line rate burst it does not really get at the root of
    the problem.

  * Idle connections.  Like the above you lose your estimate of your
    share of the network path's capacity when you don't use it.
    Just because your cwnd was N segments 30 seconds ago doesn't
    mean it will be that now.  We have a way to get the ACK clock
    going and open the cwnd -- slow start.  It should be used in
    this case.

  * Rwnd limits.  During loss recovery we'd like to continue to send
    segments into the network to keep the ACK clock going and to
    keep our estimate of the path capacity valid.  Sometimes this is
    not possible due to thr limited rwnd.  So, at the end of
    recovery we get a large cumulative ACK that gives us permission
    to send a bunch of segments.  At this point we have lost the ACK
    clock.  But, we know how to restart that -- slow start.  You'll
    end up basically doing that with maxburst.  So, just make the
    adjustments to cwnd.

  * Lost ACKs.  This case is that we send a full cwnd of N segments
    and get a single ACK (or maybe a couple) for the whole window.
    So, we burst rather than smoothly sending segments out, as if
    we'd gotten an ACK for every segment (or every other).  This is
    the case I have the most sympathy for.  One the other hand, if
    we don't have an ACK clock at a cwnd of N segments, it seems
    that maybe we shouldn't pretend we do.  Maybe we should have to
    backoff the cwnd.  Or, maybe we should have to use some sort of
    pacing or something.  Or, maybe someone more clever than I can
    come up with something for this case.

If the above is nonsense, I appologize -- I'm going to caffienate
now.

allman

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

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

---

From: Randall Stewart <[email-masked]>
Date: Mon, 04 Mar 2002 17:51:46 -0600

> document alot, though.  Basically you use your cwnd or you lose it.
Hmm.. I need to go re-read this again.. but is this the reduction
if you are not using every RTT? If so its already in 2960.... so 
we have that covered...

>     doing a line rate burst it does not really get at the root of

This was not what was specified in the current implementors guide.
The only thing it was meant for is when a FR completes... you
must apply the maxburst. The thing that we were looking to clamp
is when the rwnd=0 and the peer is waiting for the ONE FR'd chunk
to complete and thus you go from a rwnd of 0 to a rwnd of MAX in
the SACK that completes the ONE outstanding data chunk... i.e. the
one being FR'd.

>     going and open the cwnd -- slow start.  It should be used in

Here SCTP has built in that you will reduce your cwnd by 1/2 ever
RTT.

>     end up basically doing that with maxburst.  So, just make the

So at the end of a FR (in less than one RTT) you are proposing to
adjust the cwnd down so that you enter slow start - Instead of 
applying a maxburst?

>     come up with something for this case.

Hmm.. I don't think we were talking about this case but it
might be worth mulling on :>

R

-- 
Randall R. Stewart
[email-masked] 815-342-5222 (cell phone)