Re: [tcpm] draft-ietf-tcpm-rfc8312bis questions

Vidhi Goel <vidhi_goel@apple.com> Wed, 28 July 2021 07:13 UTC

Return-Path: <vidhi_goel@apple.com>
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 50C2D3A20FA for <tcpm@ietfa.amsl.com>; Wed, 28 Jul 2021 00:13:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.55
X-Spam-Level:
X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com
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 KbxF103Jckam for <tcpm@ietfa.amsl.com>; Wed, 28 Jul 2021 00:13:47 -0700 (PDT)
Received: from ma1-aaemail-dr-lapp01.apple.com (ma1-aaemail-dr-lapp01.apple.com [17.171.2.60]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D4DC3A20F6 for <tcpm@ietf.org>; Wed, 28 Jul 2021 00:13:46 -0700 (PDT)
Received: from pps.filterd (ma1-aaemail-dr-lapp01.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp01.apple.com (8.16.0.42/8.16.0.42) with SMTP id 16S6vUg0060928; Wed, 28 Jul 2021 00:13:45 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=8CjxSB/LB+uf6X6BLOsDAS9drDlPg6Kw6u4GHolok7g=; b=NkiNbqzLGAnQAKNnYUiWg1VEUwNtsAY0cjcm24QnxFagbM5LhNgZ8hn1F0fjZoL2b8g0 4s4TPXPaYfg7VqKt+qLlVvfWrvRAr2zCAiOa8J4125B0QJr99K3ETQWeIscaytsra6Zz oLz2pqJYtdNOcrjIz9gGygRXBMYmNE3ji6PmKLLJB65WpNTFbWkh4Z2TzRDMNmv/zHFC Wxh10YobY2LSlPlqcfY+LaentUuONnm1kKHWfNx67RThByi1ZvntDIuJXWNMvOMpPsxk EpXOUWAXTtxi9MOhY6LWNe4OQBS/kTE8akzWK2rn0xyDGbPbqr+P3SN3w8B2lAe1dFi+ QA==
Received: from rn-mailsvcp-mta-lapp01.rno.apple.com (rn-mailsvcp-mta-lapp01.rno.apple.com [10.225.203.149]) by ma1-aaemail-dr-lapp01.apple.com with ESMTP id 3a234gq0f8-3 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 28 Jul 2021 00:13:45 -0700
Received: from rn-mailsvcp-mmp-lapp03.rno.apple.com (rn-mailsvcp-mmp-lapp03.rno.apple.com [17.179.253.16]) by rn-mailsvcp-mta-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.9.20210415 64bit (built Apr 15 2021)) with ESMTPS id <0QWY008QZ1EXEWG0@rn-mailsvcp-mta-lapp01.rno.apple.com>; Wed, 28 Jul 2021 00:13:45 -0700 (PDT)
Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp03.rno.apple.com by rn-mailsvcp-mmp-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.9.20210415 64bit (built Apr 15 2021)) id <0QWY00M000TUN800@rn-mailsvcp-mmp-lapp03.rno.apple.com>; Wed, 28 Jul 2021 00:13:45 -0700 (PDT)
X-Va-A:
X-Va-T-CD: 766d32dce0a9c027bcd9f1f38891080b
X-Va-E-CD: a53e180a56842f1755dd6cf39cfb1647
X-Va-R-CD: 22bf1e320b833e94248c9585988464b3
X-Va-CD: 0
X-Va-ID: 09f94e83-5b01-407d-9aa6-369a46526104
X-V-A:
X-V-T-CD: 766d32dce0a9c027bcd9f1f38891080b
X-V-E-CD: a53e180a56842f1755dd6cf39cfb1647
X-V-R-CD: 22bf1e320b833e94248c9585988464b3
X-V-CD: 0
X-V-ID: 70c2b4a9-f067-4722-98c6-81c0b4b9b753
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-07-28_05:2021-07-27, 2021-07-28 signatures=0
Received: from smtpclient.apple (unknown [17.234.31.61]) by rn-mailsvcp-mmp-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.9.20210415 64bit (built Apr 15 2021)) with ESMTPSA id <0QWY009301EW8000@rn-mailsvcp-mmp-lapp03.rno.apple.com>; Wed, 28 Jul 2021 00:13:45 -0700 (PDT)
From: Vidhi Goel <vidhi_goel@apple.com>
Message-id: <012AB76C-115B-41A7-8505-D5993FCE7416@apple.com>
Content-type: multipart/alternative; boundary="Apple-Mail=_905FA06F-DA1A-4D14-A2BC-F389E521016E"
MIME-version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.11\))
Date: Wed, 28 Jul 2021 00:13:44 -0700
In-reply-to: <SA0PR00MB103641CC616E1E29A7761528B6EA9@SA0PR00MB1036.namprd00.prod.outlook.com>
Cc: "tcpm@ietf.org" <tcpm@ietf.org>
To: Praveen Balasubramanian <pravb@microsoft.com>
References: <SA0PR00MB103641CC616E1E29A7761528B6EA9@SA0PR00MB1036.namprd00.prod.outlook.com>
X-Mailer: Apple Mail (2.3654.100.0.2.11)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-07-28_05:2021-07-27, 2021-07-28 signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/l_jhLRmx4RBjVfAxQqbgXIyoc-E>
Subject: Re: [tcpm] draft-ietf-tcpm-rfc8312bis questions
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: Wed, 28 Jul 2021 07:13:49 -0000

Hi Praveen,
Following changes improve the performance of CUBIC:

1. Updated K’s definition to use congestion window at the start of congestion avoidance. More details at issue https://github.com/NTAP/rfc8312bis/issues/1 <https://github.com/NTAP/rfc8312bis/issues/1>
2. Adding lower and upper bound for CUBIC target increase - lower bound is no longer mandatory with the change in 1. The upper bound is more interesting as it will make sure that the increase function is slower than slow start. This change averts the risk of overshooting the congestion window during CA. More details https://github.com/NTAP/rfc8312bis/issues/14 <https://github.com/NTAP/rfc8312bis/issues/14>
3. Always use a minimum cwnd of 2. https://github.com/NTAP/rfc8312bis/issues/7 <https://github.com/NTAP/rfc8312bis/issues/7>
4. Change the AIMD friendly equation to use segments acknowledged instead of using time. This allows more accurate increase for cases such as rate limited apps, sending after idle etc. It also performs better with ACK thinning. https://github.com/NTAP/rfc8312bis/issues/20 <https://github.com/NTAP/rfc8312bis/issues/20>
5. When W_est > W_max, we now set alpha to 1. This makes sure that Cubic doesn’t perform worse than New Reno when we are probing for new W_max. https://github.com/NTAP/rfc8312bis/issues/2 <https://github.com/NTAP/rfc8312bis/issues/2>
6. Spurious losses result in lowering the congestion window erroneously. So, we have added guidance for handling spurious losses for CUBIC.  https://github.com/NTAP/rfc8312bis/issues/23 <https://github.com/NTAP/rfc8312bis/issues/23>

Let me know if something is unclear or if you need more info. And as always, feedback is welcome on the current draft.

Thanks,
Vidhi


> On Jul 27, 2021, at 5:54 PM, Praveen Balasubramanian <pravb@microsoft.com> wrote:
> 
> As discussed in the working group meeting, can you please clarify what behavior changes an implementation will see as a result of adopting 8312-bis versus RFC 8312? Particularly interested to know which changes will result in improved performance.
>  
> Thanks!