Subject: SCTP congestion control questions

From: "Rob + Helena" <[email-masked]>
Date: Fri, 26 Jan 2001 11:27:20 -0000

Hi All,

I have been running some SCTP congestion control simulations
and I have the following questions about the specification. I
realise that this is a bit off topic but I'm not entirely happy
with the limited responses I got on the SIGTRAN list, see
http://standards.nortelnetworks.com/scripts/wa.exe?A1=ind0101&L=sigtran#39
and any help you could give would be much appreciated.

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)

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)

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

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)

Thanks again
Rob Brennan
Dublin City University

---

From: "Randall R. Stewart" <[email-masked]>
Date: Fri, 26 Jan 2001 08:37:58 -0600

Rob:

Hmm, let me try to answer... I know we chatted on
the sigtran side a bit ago, but I am not sure I saw
your recent email. The nortelnetworks mail server seems
to be in real SAD shape right now. I am not getting ANY
mail from it and every post I send says it is not being
delivered. I don't know if this is related to blackouts in
Calif, or what ...

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

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

> This of course also drastically reduces ssthresh and cwnd.)

Yes, has we discussed earlier, I think this needs to change in
the BIS. Right now, as you rightly pointed out, the packet could
get retransmitted multiple times (as long as the cwnd allows it).
We will probably need some wording in the BIS to indicate that
once a segment as received a FR it is no longer eligible for
FR until AFTER a timeout.  This is only harmful to the sender
in reality causing a reduction in its sending rate that is
un-needed. I don't think this is a big threat, but it sure
does slow down SCTP on a long fat pipe :<

Vern/Lixia comments please?

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

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. Since if we think about the spec the current way it is written 
here is what would happen..
WARNING: My math may be a tiny bit off here, due to
         my lack of adequet coffee :) But it still
         illustrates both Rob's point 3 above AND
         my point...

Assume: 100 segments in flight
PMTU: 1500 bytes
rwnd: 300,000 bytes (big :>)
cwnd: 150000
ssthresh: 300,000bytes
each segment is exactly 1500 bytes.

<---4 the strike arrives (against number 1)----
Mark for retransmission TSN1
ssthresh = 75000
cwnd = 75000
flightsize = 148500

<----50 SACK's arrive
----Retransmit TSN1---->
(46 more SACK's still coming showing TSN1 missing)
<----4 more SACK's arrive----
Mark for retransmission TSN1
ssthresh = 37500
cwnd = 37500
flightsize = 73500
<----25 more SACK's arrive
------Retransmit TSN1------->
(17 more SACK's still coming showing TSN1 missing)
<----4 more SACK's arrive----
Mark for retransmission TSN1
ssthresh=18750
cwnd = 18750
flightsize = 34500
<---12 More SACK's arrive----
-----Retransmit TSN1------->
<------2 more SACKS and FINALLY TSN1 is acknowledged...

So at this point, I can only send 12 MTU's into the
network or so. Now this example is of course assuming
no-multihoming, since this would change the picture
somewhat :)... 12 MTU's is quite a bit smaller than the 
50 MTU burst you mention (for this example). However if
we fix 3 above, then yes we would need to fix the FR
issue and allow FR even when the cwnd does not allow it.

Vern/Lixia comments???

R

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