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

[Emmanuel Lochin <[e-mail]>]

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] 
> <mailto:[e-mail]>> wrote:
>
>     On Tue, Sep 3, 2019 at 3:31 PM Martin Duke
>     <[e-mail] <mailto:[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 list
> [e-mail]
> https://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/