Subject: Re: [tcpm] New revision: draft-ietf-tcpm-newcwv-02.txt: ssthresh

From: Gorry <[email-masked]>
Date: Thu, 1 Aug 2013 09:20:43 +0200

Interesting? I should also add this to my list.

Gorry

On 31 Jul 2013, at 09:01 AM, "Scharf, Michael (Michael)" <[email-masked]> wrote:

> Hi Andrew,
> 
> I wonder if you have experimented with setting ssthresh after an idle period to a value that is of the order of the pipeACK parameter (cf. draft-ietf-tcpm-newcwv-02 Section 4.2 - not flightsize)?
> 
> (Yes, I am aware of several other alternatives.)
> 
> Michael (without blue dot)
> 
> 
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On 
>> Behalf Of Andrew Knutsen
>> Sent: Wednesday, July 31, 2013 3:03 AM
>> To: [email-masked]
>> Subject: Re: [tcpm] New revision: 
>> draft-ietf-tcpm-newcwv-02.txt: ssthresh
>> 
>> 
>>    Given this observation, and the apparent general 
>> agreement that reducing bursts while avoiding slow-start is 
>> more important, I'm going to go ahead and bump ssthresh 
>> higher than recommended by the draft (and
>> RFC2861) in our TCP.  Increasing the RW can wait for the 
>> draft to be finalized, if we need it.
>> 
>>    Thanks for your attention.
>> 
>> Andrew
>> 
>> On 7/29/2013 11:38 PM, [email-masked] wrote:
>>> HI,
>>> 
>>> We also have observed issues with ssthresh setting after idle.
>>> This regards both TCP and SCTP usecase scenarios.
>>> 
>>> Our thoughts have been to reset ssthresh to inifinity after idle.
>>> Setting to awnd is not a good solution in SCTP (or for
>> mptcp) as the 
>>> awnd may be small even if an idle period has been observed
>> on a specific path on which traffic now resumes.
>>> 
>>> Possible SCTP or multipath issues are not within cwv, but
>> still I would like to point to this fact.
>>> 
>>> BR, Karen
>>> 
>>> 
>>>> -----Original Message-----
>>>> From: [email-masked] [mailto:[email-masked]]
>> On Behalf 
>>>> Of Anna Brunstrom
>>>> Sent: Tuesday, July 30, 2013 12:35 AM
>>>> To: [email-masked]
>>>> Subject: Re: [tcpm] New revision: draft-ietf-tcpm-newcwv-02.txt: 
>>>> ssthresh
>>>> 
>>>> Hi Andrew,
>>>> 
>>>> I agree with you that the value of ssthresh is important and that 
>>>> this part may need to be updated. If subsequent bursts are
>> not long 
>>>> enough to take you out of an unlucky state, a random loss
>> in the the 
>>>> first burst may hamper performance for all later bursts by
>> invoking CA too early.
>>>> 
>>>> We have seen the equivalent problem when you have a
>> sequence of short 
>>>> flows and the ssthresh value is cached. A random loss in one short 
>>>> flow can reduce performance for all the short flows that
>> follow. See 
>>>> our ICC paper from last year for details
>> http://dx.doi.org/10.1109/ICC.2012.6364516.
>>>> 
>>>> BR,
>>>> Anna
>>>> 
>>>> 
>>>> On 2013-07-29 21:34, Andrew Knutsen wrote:
>>>>>     I'd like to ask one question again, before we implement 
>>>>> something to avoid issues with a customer.
>>>>> 
>>>>>     Most of the discussion here seems to be about
>> avoiding bursts 
>>>>> after idle while at the same time avoiding slow-start.
>>>>> 
>>>>>     The problem we have is not slow-start after idle; its going 
>>>>> into congestion-avoidance after idle, due to an obsolete ssthresh.
>>>>> 
>>>>>     The current draft, like RFC2861, suggests setting
>> ssthresh to 
>>>>> 3/4 the old cwnd value after idle.  We've tested this, and found 
>>>>> that although it is an improvement over not doing anything (ie, 
>>>>> rfc5681), cwnd does not recover with this factor when
>> presented with 
>>>>> a series of bursts if ssthresh is low.  We've also tested with 
>>>>> setting it to  full cwnd, and to the advertised window
>> (which is the 
>>>>> receive window when idle).  Note that all of these are more 
>>>>> conservative than closing and re-opening the connection,
>> which sets 
>>>>> ssthresh to infinity (if it isn't cached).
>>>>> 
>>>>>     We've found that setting cwnd to IW after idle, and setting 
>>>>> ssthresh to awnd, allows acceptable recovery from a
>> congestion event 
>>>>> while running burst traffic.  In other words, slow-start
>> works well 
>>>>> enough from IW (it's fast compared to CA).
>>>>> 
>>>>>     We've tried to start discussion about this, but it
>> looks like 
>>>>> the consensus is a lack of concern.  While we would
>> prefer to see a 
>>>>> spec which addresses our concerns, we do have pressing
>> need to fix this issue.
>>>>> 
>>>>> Andrew
>>>>> 
>>>>> _______________________________________________
>>>>> tcpm mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/tcpm
>>>> _______________________________________________
>>>> tcpm mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/tcpm
>>> _______________________________________________
>>> tcpm mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/tcpm
>> 
>> _______________________________________________
>> tcpm mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/tcpm
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Thu, 1 Aug 2013 07:51:17 +0000

This may only be a piece of an overall solution, e.g., combined with resetting of ssthresh to the initial value (infinity in some stacks) after a longer idle period. Basically, the idle period for resetting ssthresh could be of the same order of magnitude like the local host cache timeout, in order to make restart similar to a new connection setup.

Michael

> From: Gorry [mailto:[email-masked]] 
> Sent: Thursday, August 01, 2013 9:21 AM
> To: Scharf, Michael (Michael)
> Cc: Andrew Knutsen; [email-masked]
> On 31 Jul 2013, at 09:01 AM, "Scharf, Michael (Michael)" 
> <[email-masked]> wrote:
> 
> > Hi Andrew,
> > 
> > I wonder if you have experimented with setting ssthresh 
> after an idle period to a value that is of the order of the 
> pipeACK parameter (cf. draft-ietf-tcpm-newcwv-02 Section 4.2 
> - not flightsize)?
> > 
> >> Of Andrew Knutsen
> >>    Given this observation, and the apparent general agreement that 
> >> reducing bursts while avoiding slow-start is more important, I'm 
> >> going to go ahead and bump ssthresh higher than recommended by the 
> >> draft (and