Subject: Re: SCTP congestion control questions

From: "Rob + Helena" <[email-masked]>
Date: Fri, 26 Jan 2001 18:13:32 -0000

Hi Again Randall,

thanks for taking the time to reply.
I've snipped much of the previous mail in this reply.

----------
> From: Randall R. Stewart <[email-masked]>
> > Specifically:
> > 
> > 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)
> 
> Yes, as far as I know this is true. You must obey the cwnd (and rwnd)
> for FR to kick in. I agree this means that you end up waiting 1/2 a
> window before you do the FR...  In all practicality the rwnd would
> not get in the way, since even if rwnd is set at 0, you will add
> back the size of the segment you wish to FR thus enabling the
> sending of it. It is the cwnd that will really gate you.
> 
> Vern/Lixia jump in here and give an opinion please...

I agree that this gives better throughput BUT my hunch is that
perhaps if FR always ignores cwnd it might get too agressive
in the case of multiple lost packets and persistant congestion :-(
I will have to do more simulations.

> 
> > 
> > 2. Is SCTP supposed to react with TCP-style FR in the case where it
> > receives duplicate SACKS with no Gap Ack Blocks?
> > (Generation of gap ack blocks is a "SHOULD" but the spec doesn't
> > seem to explicitly require any FR proceedure except on reception
> > of Gap Ack blocks, Sections 7 and 7.2.4)
> > 
> Hmm, good question. Duplicate SACK's would not strictly cause
> a FR if NO GAP ACK blocks showed up in it.  For example:
> 
> ----TSN101------------>
> ----TSN102-----X
> ----TSN103-----X
>      <----------ACK-101
>          XX---TSN101-->
>      <---ACK-101(Dup list 101)
> 
> There is a Duplicate list inside the SACK that would be filled with
> the duplicate. In this case SCTP would NOT consider a strike against
> TSN102 or 103 since they could well still be "in-flight" when the
> Duplicate ACK was sent. You count strikes ONLY when you receive
> an indication (i.e. the Gap Ack Block) that for sure a TSN is missing.

I don't know what this has to do with SACK duplicate lists, just assume
that a lazy implementation has not implemented the generation of Gap
Ack blocks - in this case I beleive that under the current spec there is
no way to detect loss(other than timeout). I believe that the current 
"SHOULD" should be changed to a "MUST" generate gap ack blocks.

> > 
> > 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)
> > 
> I'am not sure I am following this... tell me if I
> have it right (not enought coffee yet :>)
> 
> When you lose a packet due to FR you do the following:
> 
> ssthesh = max(1/2cwnd, 2 MTU)
> cwnd = ssthresh
> 
> 
> So are you concerned that a missing packet when the SACK finally
> catches up causes the sender to send 1/2 the previous cwnd into
> the network?  Your assuming then that the sender is using
> ordered delivery and only one stream and cannot deliver any
> of the data until the lost (FR'd) packet arrives.

Yes, but there will still be problems with mixed streams or ordered
data (although not as extreme of course).

> So I think your point here is that since you do not allow the FR
> until 1/2 a window later when the cwnd opens up, you end up
> with this giant burst (when the SACK arrives for the lost packet)
> when if you had been allowed to send the FR when you first noticed
> it (regardless of the cwnd) you would only have a 4 MTU unit burst
> to worry about (i.e. how many MTU's it took you to recognize the
> need to retransmit).
> 
> If I grok this right, this supports your argument for letting a
> FR happen no matter if cwnd allows it or not.
> 
> 
> Now, in some ways this argues against the change you propose in 
> 3. 

The change I suggested for 3 is that once a packet is FR'd it may not
be FR'd again until after a retransmission timeout. From the literature
this seems to be the standard, conservative approach. I don't understand
how this impacts on my point 4 about bursts.

> Since if we think about the spec the current way it is written 
> here is what would happen..

I think your maths is OK but I think that you are making a hidden
assumption:
That the gap counter is only reset when a packet is actually retransmitted.
The spec says "The counter increments for each consecutive SACK reporting
the TSN hole. After reaching 4 and starting the fast retransmit proceedure,
the
counter resets to 0.".

If we interpret "the fast retransmit proceedure" to mean halving cwnd,
marking
data for rtx and (only if allowed) retransmitting data then the counter is
reset
immediately every time it reaches 4. This of course triggers a collapse to
the min cwnd of 2*pathMTU when a lot of dup SACKs are in the pipe.

rgds
rob

---

From: "Randall R. Stewart" <[email-masked]>
Date: Fri, 26 Jan 2001 14:46:23 -0600

> I've snipped much of the previous mail in this reply.
Opps, I missed your point yes it should be a MUST... generating
gap ack blocks I don't think should be a option since unlike
TCP we will NOT count strikes without Gap Acks... 

> how this impacts on my point 4 about bursts.
Because if FR is bound by the cwnd then since you are collapsing 
cwnd (in the worst case to two MTU's as you note below) you will
not be sending a 1/2 window of data... at least with the
spec in the current form... 

> the min cwnd of 2*pathMTU when a lot of dup SACKs are in the pipe.
Which would make your point 4 completely invalid (besides the bad
performance issues in SCTP). But see my other point was that if
you do fix 3 (which I think we should) then we also MUST fix
4 (i.e. only one fast retransmit until a timer goes off).

1) We need to fix your item 3 by at least making it so that you
   DON'T keep retransmitting until a T-O a TSN you have done
   a fast-retransmit on.

2) Your simulations would be most welcome to see if we should need
   to ignore the cwnd and send the FR anyway.. not sure on this one.
   Since if we do NOT do that, problem 4 as you note above will
   occur...

R

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