Subject: RE: [tcpm] CWND increase after under-utilization in congestion avoidance

From: <[email-masked]>
Date: Wed, 18 Apr 2012 10:25:26 +0300

Hi,

Thanks a lot! 

My main concern is the slope of the increase of the CWND after a period of CWND underutilization in congestion avoidance phase.

My general understanding of the standards is that during slow start one may raise the CWND per received (S)ACK whereas during congestion avoidance generally CWND may be increase by one MTU only per RTT. Then some of the more experimental CC algorithms allow for slow start slope increase after a packet loss, but that may be a sidetrack here. At least my question really goes to the base standard of SCTP as specified in RFC4960. But I assume that the question is equally relevant for a TCP implementation that implements CWND validation in some form.

The assumption here is that we are in congestion avoidance phase, but also that the accumulated partical_bytes_ack can allow for several increases of the CWND within the same RTT as SACKs will be returned. Provided that the application continues to fill the increasing CWND, the question is whether SCTP (TCP) then is allowed to proactively increase the CWND several times per RTT (slow start slope) or whether the increase should be limited to be done one per RTT (congestion avoidance slope).

Thanks!

BR, Karen

-----Original Message-----
From: Matt Mathis [mailto:[email-masked]] 
Sent: 17. april 2012 22:37
To: Nielsen Karen
Cc: [email-masked]
Subject: Re: [tcpm] CWND increase after under-utilization in congestion avoidance

Well, my opinion would be that as long as  flightsize >= cwnd at least
once recently it should be ok to continue to raise cwnd.  Note that
raising cwnd probably causes the predicate to become not true.  Also
"recently" should be no shorter than one RTT, but may be a longer (the
details are not so important).   The point is that as long as FS
reaches cwnd at least once per RTT, it is fine to continue to grow the
window.  I believe I have seen it implemented "as long as FS comes
close to cwnd..."

In the big picture is it important not to keep raising cwnd if cwnd in
not controlling the connection, because then you have no way to know
if it is a valid measure of anything useful.  However, as long as cwnd
has been "tested" it is fine to keep pushing it up.

Thanks,
--MM--
The best way to predict the future is to create it.  - Alan Kay

On Tue, Apr 17, 2012 at 5:50 AM,  <[email-masked]> wrote:
> Hi,
>
>
>
> SCTP as prescribed by RFC4960 operates with CWND validation in that CWND
> increase always
>
> is subject to its fully usage. That is, CWND only may increase when
> flightsize >= CWND.
>
> Opposed to TCP, as standardized by RFC5681, CWND is thus not necessarily
> increased even when partial_bytes_ack
>
> increases beyond the present CWND.
>
>
>
> An implementation which boldly augments the partial_bytes_ack during the
> time where a CWND is underutilized (but the connection is not idle) may
> observe that the partial_bytes_ack increases to a very high value, possibly
> it increases to
>
> a value many times higher than the CWND.
>
>
>
> The question now arises what should happen once the CWND resumes fully
> utilization and thus may be increased. That is, is the intention of the
> standard of SCTP CC to have :
>
> 1.      the CWND now be increased as during "normal" congestion control
> avoidance, i.e., one MTU per acked CWND amount  of data
>
> -        Or to have -
>
> 2.      the CWND now be allowed to recapture the growth that it did not
> realize due to under-utilization but which may be recaptured from the
> partial_bytes_ack value. I.e., let it be increased one MTU per SACK until
> partial_bytes_ack has been decreased below CWND, one CWND at a time.
>
>
>
> From an implementation perspective the question likely turns into a question
> about the maintaining of the partial_bytes_ack value during the period of
> time when the CWND is underutilized. E.g., should then partial_bytes_ack be
> decreased with CWND for each times it increases beyond the CWND or should it
> be allowed to increase unlimited.  But first we need to find out what the
> intention of the standard is..
>
>
>
> The above of course is subject to cumulative SACKs and other details like
> that. I hope that we can leave such details out of the discussion.
>
>
>
> I hope that you may help.
>
>
>
> Thanks in advance!
>
>
>
> BR, Karen
>
>
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm
>

---

From: <[email-masked]>
Date: Fri, 20 Apr 2012 10:52:35 +0300

Hi,

RFC4960 specifies for the partial_bytes_ack (pba) to be uncritically increased upon receipt of SACKs. Uncritically here means also if the CWND is under-utilized, that is, also if flightsize < CWND.
Further then once traffic increases (or resumes) and the CWND becomes fully utilized and SACKs are received,
then the prescription is for the CWND to be increases one MTU provided the pba value >= CWND (and pba then set = pba - CWND)

The pba parameter first was introduced in TCP ABC RFC3465 and the parameter is used in the implementation to mimic congestion avoidance CWND increase slope of "+MTU*MTU/CWND per SACK" as specified by RFC5681.

Following the prescriptions of RFC4960 uncritically one may have the pba increase to multiple times the CWND during a
period of CWND underutilization and further, once traffic and CWND utilization resumes, one may have a situation where the CWND in principle may be increases by one MTU per received SACK (more or less) a number of times corresponding to the value INT(pba/CWND) until the pba parameter iteratively has been decreased below present CWND. This effectively results in slow start slope increase of the CWND during congestion avoidance.

Randy and Michael, as authors of the RFc4960, could I ask you to confirm that while the explicit handling of the pba in this particular case may be an implementation decision THEN THE INTENTION of SCTP CC as specified in RFC 4960 is for the CWND to be increased following congestion avoidance slope in this situation (traffic resume after CWND underutilization in congestion avoidance phase).

Many Thanks in advance !!

BR, Karen

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: 18. april 2012 09:25
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [tcpm] CWND increase after under-utilization in congestion avoidance

Hi,

Thanks a lot! 

Thanks!

BR, Karen

-----Original Message-----
From: Matt Mathis [mailto:[email-masked]] 
Sent: 17. april 2012 22:37
To: Nielsen Karen
Cc: [email-masked]
Subject: Re: [tcpm] CWND increase after under-utilization in congestion avoidance

Thanks,
--MM--

---

From: Michael Tuexen <[email-masked]>
Date: Sat, 21 Apr 2012 09:38:02 +0200

> Randy and Michael, as authors of the RFc4960, could I ask you to confirm that while the explicit handling of the pba in this particular case may be an implementation decision THEN THE INTENTION of…
Hi Karen,

the text in RFC 4960 is already in RFC 2960 and it was not intended to do anything different
than TCP CC. The first sentence of section 7.2.2 states the goal:
  When cwnd is greater than ssthresh, cwnd should be incremented by
  1*MTU per RTT if the sender has cwnd or more bytes of data
  outstanding for the corresponding transport address.
So I guess the algorithm described after that paragraph doesn't realize this goal
in the scenario you mention.

I FreeBSD we try to follow the RFC.

Best regards
Michael

---

From: Randy Stewart <[email-masked]>
Date: Sat, 21 Apr 2012 08:33:13 -0400

Karen:

As Michael stated, this algorithm was written out in RFC2960 and was not
touched in 4960 to my knowledge. I believe Lixia texted the original wording
(if my memory serves me correct). I guess the thing that is lacking is reseting
pba to 0 when you increase <or> would have increased the cwnd (but were blocked
due to other issues.. i.e. you were not using the full cwnd).

And as Michael stated, we try to follow 100% the RFC in the BSD implementation ;-)

R

>> I hope that you may help.

-----
Randall Stewart
[email-masked]

---

From: <[email-masked]>
Date: Mon, 23 Apr 2012 09:30:19 +0300

Hi,

Thanks a lot for the comments and for the confirmation.

I think, as you say, that the conclusion is that the algorithm as described in the RFC
is not complete and that it need, by implementation choice, to be adjusted 
in order to ensure that the CWND does not increase more than 1MTU per RTT in congestion avoidance.
The exact way this is achieved, either by adjusting how the pba is increased when the CWBD is underutilized or
by adjusting the CWND increase or the pba value when CWWND usage resumes (or something completely different) would then, for now at least, remain an implementation decision.

Right ?!

BR, Karen

BSD implementation can then discuss with itself how to find peace with the conflicting statements of the RFC in 
this respect. Difficult to be 100% compliant with all statements, I should think ;-) 

-----Original Message-----
From: Randy Stewart [mailto:[email-masked]] 
Sent: 21. april 2012 14:33
To: Nielsen Karen
Cc: [email-masked]; [email-masked]
Subject: Re: SCTP CWND increase after under-utilization in congestion avoidance

Karen:

R

-----
Randall Stewart
[email-masked]