Re: [TLS] Efficiency of ACKing scheme
Hanno Becker <Hanno.Becker@arm.com> Mon, 06 April 2020 14:17 UTC
Return-Path: <Hanno.Becker@arm.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EA6F3A0593 for <tls@ietfa.amsl.com>; Mon, 6 Apr 2020 07:17:05 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=exxsIbZn; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=exxsIbZn
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 1-9hJGwpz_pQ for <tls@ietfa.amsl.com>; Mon, 6 Apr 2020 07:17:00 -0700 (PDT)
Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60086.outbound.protection.outlook.com [40.107.6.86]) (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 AAB373A060A for <tls@ietf.org>; Mon, 6 Apr 2020 07:16:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=BeN1TBShU0ZfW8eb/HUrCqVDWPLbICgQvm2RiP7Z9pQ=; b=exxsIbZnYrWrs6WpO7iEBkkubayfNBfIjOw7W48lSt4eyLBdoVexhxkOBdnfcyVSGPPEiiX6APCNy3JkMMlrkaQm/Yy1Pyu8vvadJK4nqUdmzLsXk+ZK5tyDdglCX0nht456HS1Eeeka+4IcJ1K6xv6mmFqpeA/MVvT3qDgm0yA=
Received: from DB6PR0402CA0007.eurprd04.prod.outlook.com (2603:10a6:4:91::17) by DB7SPR01MB5.eurprd08.prod.outlook.com (2603:10a6:5:12::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.15; Mon, 6 Apr 2020 14:16:56 +0000
Received: from DB5EUR03FT006.eop-EUR03.prod.protection.outlook.com (2603:10a6:4:91:cafe::3d) by DB6PR0402CA0007.outlook.office365.com (2603:10a6:4:91::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.20 via Frontend Transport; Mon, 6 Apr 2020 14:16:56 +0000
Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; ietf.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;ietf.org; dmarc=bestguesspass action=none header.from=arm.com;
Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com;
Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by DB5EUR03FT006.mail.protection.outlook.com (10.152.20.106) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2856.17 via Frontend Transport; Mon, 6 Apr 2020 14:16:56 +0000
Received: ("Tessian outbound 4b84da486446:v50"); Mon, 06 Apr 2020 14:16:56 +0000
X-CheckRecipientChecked: true
X-CR-MTA-CID: 66ac854792b5957d
X-CR-MTA-TID: 64aa7808
Received: from 6ad1e0e6927d.2 by 64aa7808-outbound-1.mta.getcheckrecipient.com id AE675B1F-B9B3-417F-8F3A-4F9BEC551D6F.1; Mon, 06 Apr 2020 14:16:50 +0000
Received: from EUR03-AM5-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 6ad1e0e6927d.2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Mon, 06 Apr 2020 14:16:50 +0000
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WW89/E9Joc+J/5WzR3IIEz1wc8CVNPvOgEYIyNC8L/Pf2RVBM7dQO3iCL1zjLL9PF3Wgqw9u4ejUUJVo+Rkym/ogY/mlZ2TwIOL7+DmIfqkTAfnEDyOUdTY2XnJrRcnOKRWT91tItHga5MCVOXr3+vdfreWYWt9mZuGmi0rqpM6lKvSH17tzwl3GzY/3QG0nENbLEIpsLsRgEAfbAGQC+kB+AKGDnuu+Iq9rrwpYfUIfFIhB5mT8kMKLstMB9Sfjvvb14co4dv85kVWcwVZBA43MfW9DzOnCJFUZmJJacYlatV0KRPFfGwvGoFuWwREJq1cZ2HpKwO+F+ws+nXF5ug==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=BeN1TBShU0ZfW8eb/HUrCqVDWPLbICgQvm2RiP7Z9pQ=; b=Dp6zo5OJ6/s8ioc0+5gBZRg1TGcDdU1PZGxVDjjTNmbOTJzhZ4URzo1ApLBtcLdCeqUiirXhfifW+iPaR6xW4xnO5pqRskeWjXZcRX4DT8obY0hXO7ZhyeyAvsTl6YUOXSQlh8t8VwkeQ4Iu9EOV6QkEcZwLjMc3l5vvvRD1LzjUqIkF7HNVctOhXZs12M0nfvwaK1fEu6LyMnIJxJologpcHRKoQ5D6tECq1jUe5QqwyHCSEdbVLTTlLAEu844kWMG/VxmUxszAZZCetb3014k1fE0o3LKWMQRWXHWar0HUi1V4LUjdyWCM/2WkfwVjiFqpFwtBMLkqZKhT3EYyaA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=BeN1TBShU0ZfW8eb/HUrCqVDWPLbICgQvm2RiP7Z9pQ=; b=exxsIbZnYrWrs6WpO7iEBkkubayfNBfIjOw7W48lSt4eyLBdoVexhxkOBdnfcyVSGPPEiiX6APCNy3JkMMlrkaQm/Yy1Pyu8vvadJK4nqUdmzLsXk+ZK5tyDdglCX0nht456HS1Eeeka+4IcJ1K6xv6mmFqpeA/MVvT3qDgm0yA=
Received: from AM6PR08MB3318.eurprd08.prod.outlook.com (52.135.163.143) by AM6PR08MB4850.eurprd08.prod.outlook.com (10.255.22.76) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.16; Mon, 6 Apr 2020 14:16:49 +0000
Received: from AM6PR08MB3318.eurprd08.prod.outlook.com ([fe80::1579:b7d9:f543:200d]) by AM6PR08MB3318.eurprd08.prod.outlook.com ([fe80::1579:b7d9:f543:200d%5]) with mapi id 15.20.2878.021; Mon, 6 Apr 2020 14:16:49 +0000
From: Hanno Becker <Hanno.Becker@arm.com>
To: Thomas Fossati <Thomas.Fossati@arm.com>, Rob Sayre <sayrer@gmail.com>
CC: "tls@ietf.org" <tls@ietf.org>
Thread-Topic: [TLS] Efficiency of ACKing scheme
Thread-Index: AQHWCdUmcw6BnTFxZ0GrZHianQcZlahnnDQQgAO7OoCAAKsoAP//86kAgAAdq4D///6F3Q==
Date: Mon, 06 Apr 2020 14:16:49 +0000
Message-ID: <AM6PR08MB3318181A1F2C5B19E9392F849BC20@AM6PR08MB3318.eurprd08.prod.outlook.com>
References: <AM6PR08MB331820C710440F07055382739BC70@AM6PR08MB3318.eurprd08.prod.outlook.com> <AM6PR08MB331832C84A0E5D04AA5612A99BC70@AM6PR08MB3318.eurprd08.prod.outlook.com> <8fed27dc-f5eb-4104-8308-186c361781bc@www.fastmail.com> <6EC8987C-A1E0-454F-AF09-A43260EB2B56@arm.com> <CAChr6Sx96KBLS+VYFo7DdybraBo7ubz7ojp0fR3XjFcuGWB-2A@mail.gmail.com>, <03849701-1A14-4E1A-8298-D483E74E380C@arm.com>
In-Reply-To: <03849701-1A14-4E1A-8298-D483E74E380C@arm.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Authentication-Results-Original: spf=none (sender IP is ) smtp.mailfrom=Hanno.Becker@arm.com;
x-originating-ip: [82.132.243.166]
x-ms-publictraffictype: Email
X-MS-Office365-Filtering-HT: Tenant
X-MS-Office365-Filtering-Correlation-Id: d1c8d491-529d-40a8-362f-08d7da3529d0
x-ms-traffictypediagnostic: AM6PR08MB4850:|AM6PR08MB4850:|DB7SPR01MB5:
x-ms-exchange-transport-forked: True
X-Microsoft-Antispam-PRVS: <DB7SPR01MB5C7378EA6E7E1A1D1D5189BC20@DB7SPR01MB5.eurprd08.prod.outlook.com>
x-checkrecipientrouted: true
nodisclaimer: true
x-ms-oob-tlc-oobclassifiers: OLM:9508;OLM:9508;
x-forefront-prvs: 0365C0E14B
X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM6PR08MB3318.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(366004)(396003)(136003)(376002)(346002)(39860400002)(7696005)(66946007)(4326008)(966005)(26005)(52536014)(71200400001)(478600001)(33656002)(76116006)(55016002)(66476007)(316002)(81166006)(6506007)(186003)(9686003)(2906002)(66556008)(81156014)(8676002)(86362001)(110136005)(66446008)(64756008)(5660300002)(8936002); DIR:OUT; SFP:1101;
received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts)
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam-Untrusted: BCL:0;
X-Microsoft-Antispam-Message-Info-Original: q542A4aVoiW4oVqavvzzG5KJyRB3fbkr47V3y+i91ZQB7jE0j49MTGsBbUQVod5nRS5Zvj3Sz6K86Cs7bMGhk+4pCpSMAhCppuUq9vSF2vUThe1uPh8/GdfUwx1NymWttu0gRwUdDASBjVhSlfFSHhSyLcqFvatKRyi3iSpz78NfPNMLJc5ahD42RbOM4D29pDdh7cX2uNEbDHZaZzSkb1MziZT9sOXDrxKxCVk/5WPbYFlZTYuNK+/6FtLeeQWjSy/7oQZXy1UtDyBliPcMfS1xveb1LCjZVyMqgfMGzoCAcAthgwJNcKAlHZYhMoM71i/0k1ohQkrtgFApjpFy59aXiPTSDV93ggToOlAZXotno17KnpN7Dm1Ch4O5ZV15z5q8RFmPFVKsuEKgxplqZPHm4SefX8zkyRslqcP9F3a7Tu8blIYXt/SfRwv8ncgOE7t4INuj916Z0c6uadTdmP54LDZ8TRscObOq+XOArBosG5u3h391XRetkVzDF12eF64sehx1A3UmxoxSgRY4LA==
x-ms-exchange-antispam-messagedata: 6BOEo+yokTwX3a89MUFdDSwpzc8T5y5GhVmb3G/bC1ME3NwgO8x0MHTprad8lwLYMwfOxeUs5uN7vu99RwgK8C/4Q7A8hMqqTxVXfNfmS8Ontat2z8NQVJGkQChKcuHW8i3lv15pVeOl6hOLhPQtKA==
Content-Type: multipart/alternative; boundary="_000_AM6PR08MB3318181A1F2C5B19E9392F849BC20AM6PR08MB3318eurp_"
MIME-Version: 1.0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB4850
Original-Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Hanno.Becker@arm.com;
X-EOPAttributedMessage: 0
X-MS-Exchange-Transport-CrossTenantHeadersStripped: DB5EUR03FT006.eop-EUR03.prod.protection.outlook.com
X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(346002)(396003)(136003)(376002)(39860400002)(46966005)(26005)(70206006)(186003)(81166006)(86362001)(70586007)(8676002)(336012)(5660300002)(8936002)(47076004)(81156014)(82740400003)(7696005)(26826003)(2906002)(356004)(52536014)(110136005)(316002)(478600001)(966005)(9686003)(4326008)(33656002)(6506007)(55016002); DIR:OUT; SFP:1101;
X-MS-Office365-Filtering-Correlation-Id-Prvs: c6307565-3af8-4d34-cad0-08d7da3525ba
X-Forefront-PRVS: 0365C0E14B
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: 0as37b6/fFawYo1N0FuBJuTOqUeyKvv21AW7DlL4UbM+hmaYFcgCze2mnkp60QmQOAFKCs5vcpCOIpSy9Zj2g1ZNQww6Ofgmz6uCnb7ML7tMk5CjHFAF9i6mq8vQ+cno6SLTBBu3Ki9K+Yj8AIAKvJ7U8G6jYGuVRiVfWskpP5ostnR1gXGN41Wm29gRDlf7+tEpwmb1VcAQUKREKNDaApaSzdhcQ5ZraSpYjG+tw34g7UFeLYVfqnWCnj+oZ3agdGGp7SVqfBE4MaodwvHN0576pfh3+b3qUnLMzwEX5WNdNC7RcS8gMFP08uSq1YasAfFL35qlLugQpQrV2KSAzARAWkrPDWrfSGuwsxFZVCk3rIWSQCH0pXnp59DQRIhrPsKf3tc4aJYLI4xfUd+W0PPUsdeGX9yaDMDpClcaZirVrM0LCTCDbZVxkkdqGu0KEKf5kKi0G2MPMC1683SPf2PvJay2G6roUK+STaiBKfi1NVFQ2OgK3OsCHXvogVlbLw3qajSq4YUbBfnvQ4WrDQuMCe72f6MZxHUlaT2DGGwBLTTftsoZ+s4G0w5apanc+QEMTF6eDLODNS/5XtqC2Q==
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Apr 2020 14:16:56.5777 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: d1c8d491-529d-40a8-362f-08d7da3529d0
X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7SPR01MB5
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/KneGQycWKFy4TwEjytIVrFY9e88>
Subject: Re: [TLS] Efficiency of ACKing scheme
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 06 Apr 2020 14:17:09 -0000
Hi Thomas! > That said, as currently written, this doesn't seem to work particularly well on paths that are lossy, slow, and with small MTUs (or a combination thereof), which we need to make sure it's reasonably well covered as it happens to be one of our main use cases. > I'm inclined to say this could be solved by profiling the reliability scheme for constrained networks (in I-D.tschofenig-uta-tls13-profile), Given we agree that there is a significant inefficiency in the ACKing scheme as stated, I'd prefer we try to improve the spec now provided we find a not too intrusive way to do so, and not postpone the problem. After all, it seems that there isn't much to be changed if we go for option 2 from the original post, which perhaps isn't far off from the original intention anyway: * Sending ACKs: ACKs may be sent for any record immediately, but it is recommended to bunch ACKs and in particular send them on any sign of disruption. * Receiving ACKs: Upon receipt of an ACK, implementations should note which messages have been received and omit them from future retransmissions. It is up to the implementation to decide when to retransmit and what to retransmit, but it is recommended they retransmit after a period of time during which no further ACK messages have been received. They may also proactively retransmit parts of a flight early if an ACK message indicates a gap (note, though, that in this example one would only retransmit the gap, not the gap + tail as before). The decisive difference to the current draft is that this takes away the character of ACKs as retransmission requests (resulting from the recommendation of immediate retransmission upon receipt of a partial ACK), while it retains flexibility as to how exactly the scheme is implemented. Cheers, Hanno Cheers IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
- [TLS] Efficiency of ACKing scheme Hanno Becker
- Re: [TLS] Efficiency of ACKing scheme Hanno Becker
- Re: [TLS] Efficiency of ACKing scheme Martin Thomson
- Re: [TLS] Efficiency of ACKing scheme Thomas Fossati
- Re: [TLS] Efficiency of ACKing scheme Rob Sayre
- Re: [TLS] Efficiency of ACKing scheme Hanno Becker
- Re: [TLS] Efficiency of ACKing scheme Thomas Fossati
- Re: [TLS] Efficiency of ACKing scheme Thomas Fossati
- Re: [TLS] Efficiency of ACKing scheme Hanno Becker
- Re: [TLS] Efficiency of ACKing scheme Eric Rescorla
- Re: [TLS] Efficiency of ACKing scheme Thomas Fossati
- Re: [TLS] Efficiency of ACKing scheme Thomas Fossati
- Re: [TLS] Efficiency of ACKing scheme Hanno Becker
- Re: [TLS] Efficiency of ACKing scheme Thomas Fossati
- Re: [TLS] Efficiency of ACKing scheme Eric Rescorla
- Re: [TLS] Efficiency of ACKing scheme Thomas Fossati
- Re: [TLS] Efficiency of ACKing scheme Eric Rescorla
- Re: [TLS] Efficiency of ACKing scheme Thomas Fossati
- Re: [TLS] Efficiency of ACKing scheme Eric Rescorla
- Re: [TLS] Efficiency of ACKing scheme Hannes Tschofenig
- Re: [TLS] Efficiency of ACKing scheme Thomas Fossati
- Re: [TLS] Efficiency of ACKing scheme Hanno Becker