IETF Logo Mail Archive

Re: Consensus Calls for Transport/TLS issues, post-Cupertino

"Martin Thomson" <mt@lowentropy.net> Tue, 29 October 2019 23:46 UTC

Return-Path: <mt@lowentropy.net>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC9F11200A3 for <quic@ietfa.amsl.com>; Tue, 29 Oct 2019 16:46:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=PEfrQquI; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=EIZavS7e
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 li0_yXlRiz6f for <quic@ietfa.amsl.com>; Tue, 29 Oct 2019 16:46:18 -0700 (PDT)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5994D12006B for <quic@ietf.org>; Tue, 29 Oct 2019 16:46:18 -0700 (PDT)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id AF8D1210B8 for <quic@ietf.org>; Tue, 29 Oct 2019 19:46:17 -0400 (EDT)
Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Tue, 29 Oct 2019 19:46:17 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm3; bh=52/yrzrWpU2My/iWeMsdxP8uIn9kDU9 MpO311GDFxEc=; b=PEfrQquItdMs6VpDzSfxdt3/OkDZPxibHoYgbx9C4A96nXA D9Cowh1NIXLfc12NaconiQSVmuoG2uB29AQHvDX+ZedN9ex43OFCdgnOmLneQQqp mwW8Qa6HmL5IEnhzYBZtukUDh2hZPKoJzjyX/5VzFFc28lRXpuvz+72ytTVG/J8e XvVlJf77sskr2oBKW4oP+NyGCOzytnfsL2ajvIKsPvuxCgcLxwahGw6ZBr6H5SPO 8JKcj4Aby0LjVGN6jBBunKJNb0vJs8xQiNcnl/8U9YNWCXDj/RJzNn7iQQYKwJOL w6OlkkNp7WtElAUNrFdXpc0zYVfRXbT4KqdIFHw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=52/yrz rWpU2My/iWeMsdxP8uIn9kDU9MpO311GDFxEc=; b=EIZavS7eveuI7AdrewgR8C l7TD37GZV897gA43Wj33Dz2RYM26o3lFWX6+HdaLj65HV7gEWb6sgMqs6zdwhMwi FcYSrmyBTqAi4ZxIO9Pqw8d7ea07q7I7FrGsxPOaB/8PJFj4Gx7mbHyQbID+ROU9 qGBZT7q16D7uoN2ZSkKkYXayiOuNfYpTdpEJvj8lk4qZ6zFEfpfcPTmKsZQ9LeFb XDDoPbhfHq33Kn82Kuu3FT0YqELfSeD0MqGjamx6UwNESFfjt5gDM7xHgcJ6BeQ7 HbUXRIiL5TmoTqpUXlhw0N6otVAIeU3y7A5r3RYTym3yec+PUG/nfIDukLdBeGkQ ==
X-ME-Sender: <xms:Sc-4XW5CHZ2r3E7uLnjRS4T0I0Q-QhXLfm8_wuXyAjmF2g49fiZBAw>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedruddtvddgudegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehloh ifvghnthhrohhphidrnhgvthenucevlhhushhtvghrufhiiigvpedt
X-ME-Proxy: <xmx:Sc-4XR6k-M99vgRZjZjV7w09zZRIdboD3s3wTzyoNkTcPiq07B9DkA> <xmx:Sc-4XZyJM_J7FYThXiOJaFOgCD8GGTLNdgWL--VWl1XzgGdVAlp56w> <xmx:Sc-4XbXbR7NmCInJIS7gAchnImCzg0s1LPuKhzqk3ydvrYNR6a51fQ> <xmx:Sc-4XctgoFFiqaHpRMsGZBpHytDVWzzHeAylFM8z0XAbhur_IhFNqw>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 5E4F0E00A3; Tue, 29 Oct 2019 19:46:17 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.1.7-512-g193a140-fmstable-20191028v1
Mime-Version: 1.0
Message-Id: <f3e3b8e9-9da7-4666-bf94-03f8e0751b9a@www.fastmail.com>
In-Reply-To: <BN6PR2201MB1700E30A73DA3E8E91937C6BDA610@BN6PR2201MB1700.namprd22.prod.outlook.com>
References: <4D6397AF-B411-4E67-AFD2-76E8F2AD462C@mnot.net> <CANatvzwYA-NN+p5jLu4vpgKY_G-ZoUM03CacZWS2FAPyPqgiiw@mail.gmail.com> <BN3PR00MB0083E9A10A58F4CCC7B8A5C6B3680@BN3PR00MB0083.namprd00.prod.outlook.com> <22517ab5-9a6c-4486-b7ea-03badc064cbe@www.fastmail.com> <CANatvzx=RWB1Bio7tqX7nN_Vn1SfSaE69LZbuiU5pWeXP=BwNQ@mail.gmail.com> <DB6PR10MB176678E88FF226C2EB8FF78EAC680@DB6PR10MB1766.EURPRD10.PROD.OUTLOOK.COM> <CACpbDccOe01VBjwwy=mdSi5nync8bXa506OMTbLPpBH-hoj4Sw@mail.gmail.com> <CAPDSy+4S06qHBbitdH07Ah6gJYV+ZMY4huYLVGw14Q-n6isCrg@mail.gmail.com> <BN6PR2201MB17008576E4F8400B5DDB696FDA6B0@BN6PR2201MB1700.namprd22.prod.outlook.com> <CACpbDcf+n47NXh8XMEKx6n1fiJPZ+WyuivNmuBy1vKhZYZe6Uw@mail.gmail.com> <CAM4esxQYyTQPpF13v0AT4R=TcFOa9=UCn0nWsiqwMReYFOYDYg@mail.gmail.com> <CABcZeBM2QGC+wx-UUKMkJDqxKscOgJfhqwPhr7QXg3h-GpZwfQ@mail.gmail.com> <4d408d7a-7c50-4ccc-a42b-fb2b71b0c507@www.fastmail.com> <CABcZeBMdQPMeu862uizQYKr451Y9mvwhZ4MT7h_te5ho_Y9DOQ@mail.gmail.com> <BN6PR2201MB1700E30A73DA3E8E91937C6BDA610@BN6PR2201MB1700.namprd22.prod.outlook.com>
Date: Wed, 30 Oct 2019 10:45:59 +1100
From: Martin Thomson <mt@lowentropy.net>
To: quic@ietf.org
Subject: Re: Consensus Calls for Transport/TLS issues, post-Cupertino
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/RWty4eElcT_VTfTfiodctPN0Rto>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 29 Oct 2019 23:46:20 -0000

On Wed, Oct 30, 2019, at 05:26, Mike Bishop wrote:
> Therefore, ACK works iff we *know* that the client sent something 
> ack-eliciting in 1-RTT. 

I think that you have to make it symmetric, not just "client sends".  Because we don't have implicit acknowledgement for Handshake packets from the server, the server can enter the same state that the client does in Marten's deadlock scenario.  In other words, both need to send something ack-eliciting.  And it's not just anything at any time, it has to be anything within some bounded time.  The upper bound is probably high, but it is at least before the Handshake packets consume all the available congestion window (which might be a long time, but I haven't worked out how long that could take).

> So one solution is to require clients to send 

...and servers :)

v2.23.0 | Report a Bug | By Email