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

From: <[email-masked]>
Date: Tue, 17 Apr 2012 15:50:23 +0300

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

---

From: Matt Mathis <[email-masked]>
Date: Tue, 17 Apr 2012 13:36:38 -0700

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:
> 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
>
> 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.
>
>
>
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm
>

---

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

Thanks,
--MM--

On Tue, Apr 17, 2012 at 5:50 AM,  <[email-masked]> wrote:
> 1.      the CWND now be increased as during "normal" congestion control
> intention of the standard is..
>
>
>

---

From: Gorry Fairhurst <[email-masked]>
Date: Wed, 18 Apr 2012 17:12:21 +0100

+1

We have this individual draft that suggests how TCP should behave in 
similar cases (we plan to update this soon):
https://datatracker.ietf.org/doc/draft-fairhurst-tcpm-newcwv/

Gorry

On 17/04/2012 21:36, Matt Mathis wrote:
> Well, my opinion would be that as long as  flightsize>= cwnd at least
> On Tue, Apr 17, 2012 at 5:50 AM,<[email-masked]>  wrote:
>> Hi,
>>
>>
>>
>> is subject to its fully usage. That is, CWND only may increase when
>> flightsize>= CWND.
>>

---

From: Matt Mathis <[email-masked]>
Date: Wed, 18 Apr 2012 11:13:38 -0700

Gorry, I would love to hear how Laminar might affect your thinking.....

Thanks,
--MM--

On Wed, Apr 18, 2012 at 9:12 AM, Gorry Fairhurst <[email-masked]>wrote:

> https://datatracker.ietf.org/**doc/draft-fairhurst-tcpm-**newcwv/<https://datatracker.ietf.org/doc/draft-fairhurst-tcpm-newcwv/>
>
> Gorry
>
>
>>> ______________________________**_________________
>>> tcpm mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/**listinfo/tcpm<https://www.ietf.org/mailman/listinfo/tcpm>
>>>
>>>  ______________________________**_________________
>> tcpm mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/**listinfo/tcpm<https://www.ietf.org/mailman/listinfo/tcpm>
>>
>>
>>
>

---

From: Joe Touch <[email-masked]>
Date: Wed, 18 Apr 2012 12:15:10 -0700

I am wondering how this is expected to play out. If it's OK to send at 
the last rate - unless you hear of loss - after the app stops or things 
drain, then why not do the same during the beginning of a connection 
(which happens at most once per connection)?

We discussed the issue of restart-after-idle several times - and had 
some proposals for "use it or lose it" a while ago (it's on my idle 
queue). However, this proposal seems to easily make things much worse IMO.

I don't think TCP should "try first and recover if fail"; its premise is 
"start gently". I think that should apply to restarts as much - if not 
more - than the connection start.

Joe

---

From: Matt Mathis <[email-masked]>
Date: Wed, 18 Apr 2012 12:23:15 -0700

Joe "this proposal" refers to Gory's draft, correct?

Thanks,
--MM--

On Wed, Apr 18, 2012 at 12:15 PM, Joe Touch <[email-masked]> wrote:
> I am wondering how this is expected to play out. If it's OK to send at the
> last rate - unless you hear of loss - after the app stops or things drain,
> then why not do the same during the beginning of a connection (which happens
> at most once per connection)?
>
> We discussed the issue of restart-after-idle several times - and had some
> proposals for "use it or lose it" a while ago (it's on my idle queue).
> However, this proposal seems to easily make things much worse IMO.
>
> "start gently". I think that should apply to restarts as much - if not more
> - than the connection start.
>
> Joe
>
>

---

From: Joe Touch <[email-masked]>
Date: Wed, 18 Apr 2012 12:25:35 -0700

Yes.

On 4/18/2012 12:23 PM, Matt Mathis wrote:
> On Wed, Apr 18, 2012 at 12:15 PM, Joe Touch<[email-masked]>  wrote:

---

From: Jakob Heitz <[email-masked]>
Date: Wed, 18 Apr 2012 16:02:15 -0400

I think TCP should do what's best for TCP, not
what's best for the Internet. The Internet is quite
capable of taking care of itself these days.

Please explain how "start gently" makes TCP fast.

On Wednesday, April 18, 2012 12:15 PM, Joe Touch <> wrote:

> the last rate - unless you hear of loss - after the app stops or
> things drain, then why not do the same during the beginning of a
> connection (which happens at most once per connection)?
> 
> I don't think TCP should "try first and recover if fail"; its premise
> is "start gently". I think that should apply to restarts as much - if
> not more - than the connection start.
> 
> Joe

-- 
Jakob Heitz.

---

From: Joe Touch <[email-masked]>
Date: Wed, 18 Apr 2012 13:11:10 -0700

> capable of taking care of itself these days.

I'm not sure how to address your viewpoint. It's so drastically 
inconsistent with how TCP has evolved and been shepherded by this WG and 
the IETF it's hard to know where to start.

> Please explain how "start gently" makes TCP fast.

It doesn't. That's a different optimization that is contrary to much of 
the design of TCP.

TCP is intended to go 'only as fast as it can while being fair to other 
TCPs and without causing problems' - both for itself and the rest of the 
Internet.

Joe

>
> On Wednesday, April 18, 2012 12:15 PM, Joe Touch<>  wrote:
>

---

From: Jakob Heitz <[email-masked]>
Date: Wed, 18 Apr 2012 17:01:16 -0400

On Wednesday, April 18, 2012 1:11 PM, Joe Touch <mailto:[email-masked]> wrote:

> It doesn't.

That's the issue.

-- 
Jakob Heitz.

---

From: Wesley Eddy <[email-masked]>
Date: Wed, 18 Apr 2012 17:35:45 -0400

> Please explain how "start gently" makes TCP fast.

How about by avoiding time spent detecting and responding
to losses?  That's good for TCP.

"Fast" in terms of throughput is a pretty naive metric to
optimize, when we also need to avoid packet losses and
excessive delays presented to the application.  I think
those concerns lead to careful consideration of the issue.

-- 
Wes Eddy
MTI Systems

---

From: rick jones <[email-masked]>
Date: Wed, 18 Apr 2012 18:59:35 -0700

On Apr 18, 2012, at 12:15 PM, Joe Touch wrote:

> I am wondering how this is expected to play out. If it's OK to send at the last rate - unless you hear of loss - after the app stops or things drain, then why not do the same during the beginning of a connection (which happens at most once per connection)?
> 
> We discussed the issue of restart-after-idle several times - and had some proposals for "use it or lose it" a while ago (it's on my idle queue). However, this proposal seems to easily make things much worse IMO.
> 
> I don't think TCP should "try first and recover if fail"; its premise is "start gently". I think that should apply to restarts as much - if not more - than the connection start.

I've never been all that fond of slow-start after idle, taking the position that at connection start TCP (presumably) knows nothing but it knows *something* in the middle of a connection.  Yes, it may age quickly, so if you were to go to the extreme and ask about it being idle for days, hours or maybe even minutes I might agree that what it knows is old and increasingly suspect, but for a few RTOs I'd be inclined to let it start where it left-off.

rick jones
there is no rest for the wicked, yet the virtuous have no pillows

---

From: Joe Touch <[email-masked]>
Date: Thu, 19 Apr 2012 09:45:36 -0700

> I've never been all that fond of slow-start after idle, taking the position that at connection start TCP (presumably) knows nothing but it knows *something* in the middle of a connection.  Yes, it…

You might look at the "use it or lose it" approaches that were proposed 
a few years ago:

http://www.isi.edu/touch/pubs/draft-hughes-restart-00.txt

The point is that the CWND info should 'decay'. We didn't converge on 
the timescale of that decay.

However, decaying CWND within a connection during restart is no 
different than the idea of decaying CWND between successive connections 
- see RFC 2140.

While I agree that the decay should be considered, I suspect that the 
vast majority of the cases go idle long enough that they're no different 
from connection starts, though.

Joe