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

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

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

On Wed, Apr 18, 2012 at 9:12 AM, Gorry Fairhurst <gorry@erg.abdn.ac.uk>wrote:

> +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/<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
>> 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,<Karen.Nielsen@tieto.com>  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
>>> tcpm@ietf.org
>>> https://www.ietf.org/mailman/**listinfo/tcpm<https://www.ietf.org/mailman/listinfo/tcpm>
>>>
>>>  ______________________________**_________________
>> tcpm mailing list
>> tcpm@ietf.org
>> https://www.ietf.org/mailman/**listinfo/tcpm<https://www.ietf.org/mailman/listinfo/tcpm>
>>
>>
>>
>