Subject: Re: SCTP congestion control questions

From: Mark Allman <[email-masked]>
Date: Mon, 05 Feb 2001 13:30:06 -0500

Ugh -- it is not clear that this is the place to discuss this,
but... 

> 1. Should the SCTP fast retransmit proceedure respect cwnd/rwnd
> when retransmitting a packet?
> (Section 6.1 of the spec seems to state yes, but this means that FR
> is not very fast :-) as it must wait for approx 1/2 a window of duplicate
> SACKs to arrive before it can do the retransmit)

It should ingore the rwnd, for sure.  I think that since you are
retransmitting you are simply replacing something in the window, not
adding to it.

I also think you *should* ignore cwnd (I don't remember the SCTP
spec), but RFC 2581 says that you should retransmit -- I don't
believe there is any mention of a check to cwnd.

> 3. The FR proceedure outlined in section 7.2.4 (especially the
> implementation note) seems to lead to multiple retransmits of
> the same packet in the case where there is a large number of
> duplicate ACKs arriving. 
> (counter goes to 4, packet is FR'd, counter is reset, 4+ duplicate
> sacks arrive before 1 rtt => packet is FR'd again.
> This of course also drastically reduces ssthresh and cwnd.)

I agree this seems busted.

> 4. 1 Packet loss with large windows, high bandwidth and long rtts
> can lead to very large bursts of up to half a window of packets.
> Does the spec (or current best practice) address this?  (1 pkt
> lost => cwnd =1/2 ssthresh, receiver buffer fills with 1 window of
> data => a_rwnd = 0, then retransmitted pkt arrives => a_rwnd =
> full size of buffers, when this SACK arrives sender can transmit
> cwnd (ie 1/2 ssthresh) packets immediately)

Again, I am not sure what the spec says, but you should be sending
new data during the "recovery phase".  After half a RTT worth of
duplicate ACKs goes by you should then start sending a new (never
sent) segment per duplicate ACK.  Therefore, when loss recovery ends
you will have outstanding data and therefore no huge burst of loss.
I know this is in the SCTP document in spirit.  I thought it seemed
correct to me when I read it.  

(Also, rwnd can limit the sending of new data during recovery and
cause a big burst.  We might think about using something like CWV
(RFC 2861) in SCTP.bis to prevent such bursts.).

allman

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

---

From: Kacheong Poon <[email-masked]>
Date: Mon, 5 Feb 2001 19:50:27 -0800 (PST)

> believe there is any mention of a check to cwnd.

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.

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.

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.

							K. Poon.
							[email-masked]

---

From: "Randall R. Stewart" <[email-masked]>
Date: Tue, 06 Feb 2001 11:51:26 -0600

Mark:

Some comments below...

> retransmitting you are simply replacing something in the window, not
I don't think the rwnd is ever an issue. Since when you
do a FR you:

A) Add back the packet to the rwnd you have left
and
B) Then go to do the FR..

So you never should hit the problem that the FR is gated
by the rwnd... as long as you FR right away :/

> believe there is any mention of a check to cwnd.

I believe this may be broke in the spec. I have re-issued the
bake-off draft to include this item.

> I agree this seems busted.

Yep, this is also listed to be fixed in the BIS (in the
bake-off draft).

> (RFC 2861) in SCTP.bis to prevent such bursts.).

Two things to note:

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

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... 

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 :)

R

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

---

From: "Randall R. Stewart" <[email-masked]>
Date: Tue, 06 Feb 2001 11:54:31 -0600

Kacheong:

A minor comment.

> The stack should not fast retransmit the whole half window at once.
You are never allowed (according to RFC2960) to send more than
ONE single packet at the time a retransmit is determined... either
by FR or T-O. So for any one feedback event/SACK you should never
respond with more than one RETRANSMIT...

R

---

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

> next release of the ref-implementation :)

There is a variant of maxburst called burst-or-lose (Touch/Floyd)
that combines the need to avoiding bursts due to retransmissions and
avoiding bursts after idle periods. It was described in 
an old ID, which is still somewhat in process (though not active).
An archived version of the ID is at:

	http://www.isi.edu/touch/pubs/tcpimpl-restart-01.txt

(from an email of mine from back in Sept):

> ...regarding MaxBurst,
> Sally's version was a 'per send call' limit. It assumes that "send" is called
> on every ACK or timeout event (an implementation detail), and limits only
> stretch-ACK related bursts. MaxBurst:
> 
>         - resets the count inside the send-call to N=5
> 
> The variant called Burst or Lose" (in the earlier e-mail) augments MaxBurst
> in a few ways:
> 
>         - it retains the count (N=3 or N=5) between send-call invocations
>         - it resets the count on ACKs (not dupacks, though) and timeouts
>                 this is a 'reset to N' - it doesn't increment beyond N
> 
> The goal of BOL is twofold:
> 
>         - avoid stretch-ACK bursts
>         - avoid bursts due to source stream burstiness (idle then active)
> 
> Joe