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

Hi,

I am sorry to bother you again.
My emails to tsvwg generally bounces back...

I do not know if you are interested in the following topic.

We have checked the BSD code and it seems that BSD SCTP allows for 
slow start type increase of the CWND if the accumulated partial_bytes_ack allows 
after a situation with CWND underutilization in congestion avoidance phase.

Do you know if that is a conscious choice and/or if that is how you
see the RFC4960 precription ? (which then is perfectly mute on what to do with
the partial_bytes-ack value in this situation).

Actually I/we think that it should not be like this, namely that the partial_bytes_ack should not be allowed to increase much above CWND - so that it will allow for only one +MTU increase of the CWND per RTT in congestion avoidance phase.

It is then an implementation decision as to how exactly to handle the partial_bytes_ack in the under-utilization phase and which value to start with once the condition for CWND (flightsize >= CWND) resumes to be met.

BR, Karen

-----Original Message-----
From: Nielsen Karen 
Sent: 18. april 2012 09:25
To: 'Matt Mathis'
Cc: ; 
Subject: RE: [tcpm] CWND increase after under-utilization in congestion avoidance

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  
Sent: 17. april 2012 22:37
To: Nielsen Karen
Cc: 
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 KayOn Tue, Apr 17, 2012 at 5:50 AM,   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
> 
> https://www.ietf.org/mailman/listinfo/tcpm
>