Re: [tcpm] draft-ietf-tcpm-rack-05 review

[Yuchung Cheng <[e-mail]>]

Hi Emmanuel,

Yes setting the sysctl to 0 will completely disable RACK. Although by
default it supports DUPTHRESH-based detection (as a simple extension)
beside time-based detection. You can disable that extension w/ 0x4. But if
you want absolutely old-style pure DUPTHRESH-based then you can set that to
0.



On Fri, Sep 6, 2019 at 3:24 AM Emmanuel Lochin <
[e-mail]> wrote:

> Hi Yuchung, all,
>
> I have a question concerning the GNU/Linux kernel implementation of RACK.
> There are 3 sysctl options to enable RACK (0x1 0x2 and 0x4) but none to
> disable it (or may be 0x0 is not documented). As tcp_input.c implements
> this boolean function:
>
> static bool tcp_is_rack(const struct sock *sk)
> {
>         return sock_net(sk)->ipv4.sysctl_tcp_recovery &
> TCP_RACK_LOSS_DETECTION;
> }
>
> can I consider that I can disable RACK by typing sysctl -w
> net.ipv4.tcp_recovery=0 ?
> I ask this question because I've seen several update done inside the
> kernel to implement it and I want to be sure that I can really go back to
> 3DUPACK scheme this way.
>
> Cheers,
>
> Emmanuel
>
> Le 05/09/2019 à 04:44, Martin Duke a écrit :
>
> I think the proposed text is fine.
>
> On Wed, Sep 4, 2019 at 5:55 PM Yuchung Cheng <[e-mail]> wrote:
>
>> On Tue, Sep 3, 2019 at 3:31 PM Martin Duke <[e-mail]>
>> wrote:
>>
>> <snip>
>
>
>> > (3) sec 7.3
>> >
>> > We have evaluated using the smoothed RTT (SRTT from
>> >    [RFC6298] RTT estimation) or the most recently measured RTT
>> >    (RACK.rtt) using an experiment similar to that in the Performance
>> >    Evaluation section.  They do not make any significant difference in
>> >    terms of total recovery latency.
>> >
>> > If there is truly no difference, then why not use SRTT as the standard?
>> > Every TCP implementation has to store this, while min_rtt is unneeded
>> for many (most?) congestion controls.
>> >
>> > Alternatively, you could strengthen this paragraph to not sound like it
>> makes no difference..
>> That's a good point -- our experiment at Google servers indeed didn't
>> show much difference. But I think it's still better to use min_RTT
>> than SRTT. On buffer-bloat friendly C.C. the SRTT could be orders of
>> magnitude longer than the actual paths' RTT -- in my opinion factoring
>> this network queuing delay in reordering window is not a good idea. So
>> how about adding
>>
>> 'While the experiment does not show a difference between min RTT and
>> SRTT, SRTT is less desirable to size the reordering window as it
>> includes network congestion or delayed ACKs effects."
>>
>>
>>
> _______________________________________________
> tcpm mailing [e-mail]://www.ietf.org/mailman/listinfo/tcpm
>
>
> --
> Emmanuel LOCHIN
> Professeur ISAE
> ISAE SUPAERO - Institut Supérieur de l'Aéronautique et de l'Espace
> 10 avenue Edouard Belin - BP 54032 - 31055 TOULOUSE CEDEX 4 FRANCE -http://www.isae-supaero.fr
> Tel [phone] - Fax [phone]
> Web : http://personnel.isae.fr/emmanuel-lochin/
>
>