From nobody Fri Jun 17 12:48:58 2022 Return-Path: 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 38AB4C157B50 for ; Fri, 17 Jun 2022 12:48:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.785 X-Spam-Level: X-Spam-Status: No, score=-3.785 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-1.876, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FDJ3hosUyp29 for ; Fri, 17 Jun 2022 12:48:53 -0700 (PDT) Received: from mx36-out21.antispamcloud.com (mx36-out21.antispamcloud.com [209.126.121.69]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACCA4C157B33 for ; Fri, 17 Jun 2022 12:48:53 -0700 (PDT) Received: from xse304.mail2web.com ([66.113.197.50] helo=xse.mail2web.com) by mx256.antispamcloud.com with esmtp (Exim 4.92) (envelope-from ) id 1o2HxX-000Gw9-N8 for quic@ietf.org; Fri, 17 Jun 2022 21:48:49 +0200 Received: from xsmtp22.mail2web.com (unknown [10.100.68.61]) by xse.mail2web.com (Postfix) with ESMTPS id 4LPqMn1h0FzB1P for ; Fri, 17 Jun 2022 12:48:05 -0700 (PDT) Received: from [10.5.2.49] (helo=xmail11.myhosting.com) by xsmtp22.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1o2Hwr-0007ly-3M for quic@ietf.org; Fri, 17 Jun 2022 12:48:05 -0700 Received: (qmail 3469 invoked from network); 17 Jun 2022 19:48:04 -0000 Received: from unknown (HELO [192.168.200.66]) (Authenticated-user:_huitema@huitema.net@[72.235.197.84]) (envelope-sender ) by xmail11.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 17 Jun 2022 19:48:04 -0000 Message-ID: <9630bd8d-08f4-3fa8-d425-dcc1739e9b7e@huitema.net> Date: Fri, 17 Jun 2022 12:48:02 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.10.0 Content-Language: en-US To: Michael Eriksson , IETF QUIC WG Cc: Rebecka Alfredsson References: <2185c80f-2d67-4603-94c1-733f6092cea7.> <6fcb0ab4-60ea-4eb2-a8c1-fefcbc2fea7f.miaoji.lym@alibaba-inc.com> <3536dd02-b52f-2372-9920-314ae4c15b12@huitema.net> <4c7969d9-a0cd-a25d-9836-5a5115283867@ericsson.com> <2a6d4c6f-6168-0e19-e596-49f3dbca419c@huitema.net> <2af86b8a-1346-3b1a-4227-d86a84103f97@ericsson.com> From: Christian Huitema Subject: Re: Heads up -- unifying of multipath options. In-Reply-To: <2af86b8a-1346-3b1a-4227-d86a84103f97@ericsson.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: 66.113.197.50 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 66.113.197.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.197.0/24@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: unsure X-Spampanel-Outgoing-Evidence: Combined (0.15) X-Recommended-Action: accept X-Filter-ID: Pt3MvcO5N4iKaDQ5O6lkdGlMVN6RH8bjRMzItlySaT9WLQux0N3HQm8ltz8rnu+BPUtbdvnXkggZ 3YnVId/Y5jcf0yeVQAvfjHznO7+bT5x6h2yQpzTslcOqazQkKtAFKj/EwzSHE5FGYwwjsNRPCGRv U5hphI/IzHqHnXjbgoTmD6wdmZPcItWbGe10hXJtXL4FsauCVkDjmcYJdU3yWp7KuHNaaKdg7iBE ZefdsNUFWKwa/wzJUjmazeC7Imca44amlqA1DMizheOpkPv9TBQ6V51u76v35b1wNe/MvdIASZp0 7mnQqdezZCtq+A712+J9PgaoF8SQHto3le4zsHTaeQtlKubP6iUTjj6yPARK6buALVaA782LKxg6 vRmng8N1aLhXqdc+jC1RcnVud53D5caUhbVtvqItBqoizkEt9O20UjkwI0v+LOlw05G4BS+iyyNq bT8dUMXMJ4tUCMj6G37ZfAMLceP5aNHPt26RBupu5v1nytoNnc138GfEJRQ2qC7jjynPIHPNqSn4 QTXUjLjYWQt1/5xnQymMoPsgr/U0flMcy2Vi/IcBgY4arPaiJ1W6hAyiRC61jekdwIcXNugoOEbH RyFULpSjm7hMIABpqqRGKyDs8xujM3cqKtEyjRS48tkuSWBkVvcslK7uU8ou62p941zuP5yi/i1j L99vRtjulKPrgmJGIGEWEnFzsC48bTEFY06/YbB87Ww8G0LoS8V3Mt1pta8qAcLtCB3G1CwpaI3Z 4ESkMWDVJEenxBoIht3V0nekAoxXAol9pFAOazwVAf4vSD1/TLuyuLfHqAnAj7rgKH7+eCmmtCKn rte370Ebb1Gy+Bf7qlShcA6Xvva2QAVEjpqzANap+28aWyCRVT7YkY7LckVcauuYsh2QHu0cH4Kz dDaq2713qFZSq8Fx+9otn0aqja8VKPqpdskk5LxBR/9t1zMMkdu6/R2FM84kxYRFSvC1IDg1BRW7 hzp8w3iHcOwbVtsmWfnQGGis4EvbR3jXsI0ESXwhBU2hwt/J18C+HygJl/jEzm1SsR8v3aJbN/NZ fa8pHhHaz+HPa0HAgEx4sWDF X-Report-Abuse-To: spam@quarantine11.antispamcloud.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2022 19:48:58 -0000 On 6/17/2022 6:08 AM, Michael Eriksson wrote: > On Thu, 16 Jun 2022 18:21:38 -0700, Christian Huitema wrote: > > On 6/16/2022 2:08 AM, Michael Eriksson wrote: > > > You claim that a single PN space makes hardware offload easier, > > > which is against my understanding after having supervised Rebecka > > > Alfredsson's master thesis project on hardware offload for > > > multipath QUIC. As I wrote in a previous message, receive-side > > > hardware offload needs to expand the received compressed packet > > > number to a full packet number to be able to decrypt the packet. > > > This is hard to do if there are holes in the packet number > > > sequence, which will happen if you have a single PN space. To be > > > explicit, different paths can arrive on different offloading NICs > > > or be handled by different threads due to load-balancing > > > mechanisms similar to receive-side scaling (RSS). The same problem > > > could affect more abstract designs, such as those based on P4. > > > > I think that the PN expansion issue is not decisive. Yes, there will > > be holes. An interface specific encryption offload engine will only > > see a fraction of the traffic. But if that fraction is large enough, > > no problem -- even if the increase is not monotonous, the stream of > > packets is sufficient to maintain a good idea of the current PN > > number range. If the fraction is too low for that, that also means > > that the interface is very lightly used. In that case, the overhead > > of an occasional synchronization between hardware and software can > > be absorbed with little impact on performance. > > Here we definitely disagree. Why go for a solution that has obvious > fundamental problems when they can be easily avoided by choosing > another solution? There are no "obvious fundamental problems" with the single PN solution. It is demonstrated to work in multiple tests, and it provides performance on par with the multiple PN variant. The only problem that may need solving is the tracking of ECN, which could easily be provided by a "PATH REPORT" frame independent of the ACK frame. > > > > With the single space solution, the same encryption logic is used > > regardless of whether the connection supports multipath or not. I > > think that makes implementation of crypto offload simpler. The same > > encryption key and IV are used for all paths, and that too makes > > encryption offload simpler, especially when handling key rotations. > > In Rebecka Arvidsson's prototype, the exact same encryption logic is > used regardless of whether the connection supports multipath or not. > The single path of a unipath connection has the ID zero and it just > works. That may be true in your case, but it is not true in general. Per RFC 9000, the CID changes after path migration. It can also change in an arbitrary way if the clients decides to do it, maybe for privacy reasons. And it will definitely have to change if the TTL of the CID expires and the server issues "retire CID" requests. > > > > But all this is only relevant if we go back to the drawing board and > > insist on picking exactly one solution. That's not what the unifying > > PR proposes. With that PR, the single number space is only used in > > conjunction with zero-length identifiers. The node deploying crypto > > offload will only need to deal with PN number holes if it chooses to > > use zero-length identifiers. In practice, the kind of big servers > > that deploy encryption offload don't do that. They tend to sit > > behind load balancers, and the defined CID are very much required to > > support multipath through a load balancer. So, I don't think that we > > have a problem in practice. > > Again, why chose a solution with obvious inherent problems when there > is a much better one available? > > Don't forget that the unified solution is also unable to handle ECN on > path's with zero-length connection IDs. ECN is needed for L4S, which > Apple has now made available as a beta in iOS 16 and macOS Ventura. > > https://developer.apple.com/videos/play/wwdc2022/10078/ Correct. There is also text to that effect in the PR, with proposed mitigations. It could be fixed quite simply, see comment above about the need of a PATH REPORT frame. > > > To be honest, it's really hard to understand why you hold on to a > solution that has obvious problems. I have shown how they can be > avoided, in a way that also has much lower complexity. Not true. The management of path identifiers and PN does increase complexity quite a bit if you cannot rely on CID. -- Christian Huitema