Re: [tcpm] draft-ietf-tcpm-rack-05 review
Emmanuel Lochin <emmanuel.lochin@isae-supaero.fr> Fri, 06 September 2019 10:24 UTC
Return-Path: <Emmanuel.LOCHIN@isae-supaero.fr>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A33B12006D for <tcpm@ietfa.amsl.com>; Fri, 6 Sep 2019 03:24:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sonbJByABs3n for <tcpm@ietfa.amsl.com>; Fri, 6 Sep 2019 03:24:03 -0700 (PDT)
Received: from smtpextng.isae.fr (smtpextng.isae.fr [192.93.254.80]) by ietfa.amsl.com (Postfix) with ESMTP id 43191120058 for <tcpm@ietf.org>; Fri, 6 Sep 2019 03:24:03 -0700 (PDT)
Received: from smtp-int-tech (smtp-int-tech.isae.fr [10.132.1.56]) by smtpextng.isae.fr (Postfix) with ESMTP id DA72171273; Fri, 6 Sep 2019 12:24:00 +0200 (CEST)
Received: from smtp-secung (smtp-secung.isae.fr [192.93.254.79]) by smtp-int-tech (Postfix) with ESMTP id D07F34925AE; Fri, 6 Sep 2019 12:24:00 +0200 (CEST)
Received: from [192.168.1.128] (c2s31-2-83-152-88-205.fbx.proxad.net [83.152.88.205]) by smtp-secung (Postfix) with ESMTPSA id 9E8C170CBA; Fri, 6 Sep 2019 12:24:00 +0200 (CEST)
To: Yuchung Cheng <ycheng@google.com>
Cc: "tcpm@ietf.org Extensions" <tcpm@ietf.org>
References: <CAM4esxQR5zeHC0g0MmCG3iF2js_2BU6+tdwCKi4ZiGFYMr5MRg@mail.gmail.com> <CAK6E8=f2fhOk_-_zq=cj+Bh13kGdVUsZNi+FvYcjtnbJdLDXbg@mail.gmail.com> <CAM4esxTj1A226PP1wNcdxwb_aXQemp-qX_7CpKYcjs5qyJH+Qg@mail.gmail.com>
From: Emmanuel Lochin <emmanuel.lochin@isae-supaero.fr>
Message-ID: <84fac75f-07ea-e3a1-b9cd-33ffc8a6d454@isae-supaero.fr>
Date: Fri, 06 Sep 2019 12:24:00 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <CAM4esxTj1A226PP1wNcdxwb_aXQemp-qX_7CpKYcjs5qyJH+Qg@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------1364D7E51B8C058D611462F6"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/EDT2RlNnfnATcf0Sd6bmEednyP4>
Subject: Re: [tcpm] draft-ietf-tcpm-rack-05 review
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 Sep 2019 10:24:07 -0000
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 <ycheng@google.com > <mailto:ycheng@google.com>> wrote: > > On Tue, Sep 3, 2019 at 3:31 PM Martin Duke > <martin.h.duke@gmail.com <mailto:martin.h.duke@gmail.com>> 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 > tcpm@ietf.org > 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 +33 5 61 33 84 85 - Fax (+33) 5 61 33 83 45 Web : http://personnel.isae.fr/emmanuel-lochin/
- [tcpm] draft-ietf-tcpm-rack-05 review Martin Duke
- Re: [tcpm] draft-ietf-tcpm-rack-05 review Yuchung Cheng
- Re: [tcpm] draft-ietf-tcpm-rack-05 review Martin Duke
- Re: [tcpm] draft-ietf-tcpm-rack-05 review Emmanuel Lochin
- Re: [tcpm] draft-ietf-tcpm-rack-05 review Yuchung Cheng
- Re: [tcpm] draft-ietf-tcpm-rack-05 review Emmanuel Lochin
- Re: [tcpm] draft-ietf-tcpm-rack-05 review Yuchung Cheng
- Re: [tcpm] draft-ietf-tcpm-rack-05 review Yuchung Cheng