AEAD and header encryption overhead in QUIC
Kazuho Oku <kazuhooku@gmail.com> Thu, 18 June 2020 08:23 UTC
Return-Path: <kazuhooku@gmail.com>
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 C504E3A0F93 for <quic@ietfa.amsl.com>; Thu, 18 Jun 2020 01:23:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 gdeYzgJm8g9Z for <quic@ietfa.amsl.com>; Thu, 18 Jun 2020 01:23:57 -0700 (PDT)
Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [IPv6:2a00:1450:4864:20::52e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D76473A0F91 for <quic@ietf.org>; Thu, 18 Jun 2020 01:23:56 -0700 (PDT)
Received: by mail-ed1-x52e.google.com with SMTP id k8so4190311edq.4 for <quic@ietf.org>; Thu, 18 Jun 2020 01:23:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=RB2LyGmEEbeJX2lFmECaRShcWyDjiH/Ic/oflYy7rpM=; b=THodY3Hua875Lt0cioeZw7/1c3hGi5g1afotkJx+1VAJ5ZR2TnmshEJmZQgPpgD76H GcE5gjoSzYm6C21/lV2/YfeSvVIkt3R4oowbLcB6SjaVFAlWHaHJ1xVJDboMrsfeqcxg hMwYhTh8diNQ6wjz78I9AxjJQaomCapU9aOiIpfQ6QlO5ZDtB+mJ/7WAJrcDSa7MZVNG 6WGP5HABmg40jqVgE+bTGYvSQzzxCILywJZ857uCf/3HKyreps4RP++OKSjJFBvtDbxD tVVFilyjCy4RBERe9tCs4Rjstfe1P57tfsg8zfBJYEONm36SPAfNhS8K+dkJJEfvyCty quEA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=RB2LyGmEEbeJX2lFmECaRShcWyDjiH/Ic/oflYy7rpM=; b=LPWA5tsKCX1c3y2C9/6X/hbh5BVX9PNG9Y5KE6VbmNVCBA91uwXYgf9kDJeiHMoloU 98D1qen9VGd1+v9DM2EDoViWpnnzoRVZmTgIbBXuGydKVghbkYLiJj7hXROg58k61aQ6 EbV9vpefDogI41LxYZAvQEs8w1ZNoU+CvF46jgIvq8vhCRZebrcTYL0UUbJGHDUe+/JD yg+UnqZuoWh+ycEui7GLNPYoRC22m0Gfq+X2jEt5D2sX//azTbrp8wgUxL617XNq0aiP ecN3UW7K8aZk34tDhc7OFQzqQWt8nsHEAO05B7Cd7W+e0KDCiw77BCw5fZB/+Mi7UO1O d1yQ==
X-Gm-Message-State: AOAM530zPugqLNyU1NFQPKpeX0pv/H16PRzhU6dH+9+RZNxdr3D4of3m uANmLkz4X9syC6x7tZsH4AAVJt03n5wVqYiwKchC/snn
X-Google-Smtp-Source: ABdhPJwT8voZ0iunGWWzvxmsfqNL+NyrFPEZamp2yxSvqZAO7UgInXpC7uNMlLmzV9NsnNYu8mrBCC9gHjRXXcJw+Ls=
X-Received: by 2002:a05:6402:362:: with SMTP id s2mr2968770edw.337.1592468635103; Thu, 18 Jun 2020 01:23:55 -0700 (PDT)
MIME-Version: 1.0
From: Kazuho Oku <kazuhooku@gmail.com>
Date: Thu, 18 Jun 2020 17:23:44 +0900
Message-ID: <CANatvzz8F1H=DXMkBEhmKHnYM-HVG48TS9KwY=OP881Txkcodw@mail.gmail.com>
Subject: AEAD and header encryption overhead in QUIC
To: IETF QUIC WG <quic@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000004fb7db05a8577f73"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/OnBhC4gCosmlU3VKoFk_jJnpeXU>
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: Thu, 18 Jun 2020 08:23:59 -0000
Hello folks, TL;DR: When existing crypto libraries are used, the AEAD cost of QUIC can become somewhat greater than that of TLS over TCP, due to those crypto libraries not optimized for handling short AEAD blocks. Crypto libraries optimized for short AEAD blocks can tighten the gap. Also, crypto libraries optimized for QUIC can combine AEAD operation and header protection vector generation, effectively eliminating the cost of header protection. A bit longer story: Recently, when testing quicly [1] using a NIC with *hardware support* for UDP GSO offload, we noticed that it uses +30% CPU cycles compared to TLS over TCP. This was due to our underlying crypto not being optimized for short AEAD blocks, and due to the call overhead of doing header protection one packet at a time. [2] We went on to implement our own AES-GCM library optimized for short AEAD blocks (i.e. packet-sized), that also generates the header protection vector while doing AEAD computation. By switching to the new crypto library, the performance drawback of the crypto itself compared to large AEAD blocks when down from 30% to 10% [3]. The overhead of header protection (relative to all the crypto cost) on the send side is now between 0.3% to 1% when using packets sized around 1400 bytes to 1500 bytes. The ratio against the total transport cost is going to be less than that, and in practice, I think that they are negligible. The story might be a bit different on the receive-side due to the dependency between header protection and AEAD, though I am sure there would also be ways to optimize. In terms of CPU cycles spent by the QUIC stack, the overhead compared to TLS-over-TCP came down to 5%. quicly can now sustain the send rate of 5Gbps while spending about 30% of CPU cycles of one modern Intel CPU core [2]. These numbers are observations from one TLS / QUIC stack doing micro-benchmarks, though I tend to think that sharing performance numbers lead to people having better expectations regarding the CPU cost of QUIC. Some of us were also concerned about the cost of header protection (a.k.a. packet number encryption) [4]. Hence posting here. [1] https://github.com/h2o/quicly [2] https://github.com/h2o/quicly/pull/359 [3] https://github.com/h2o/picotls/pull/310 [4] https://mailarchive.ietf.org/arch/msg/quic/Wy8JXwKyeYgWgRWizWDbyOLg0xc/ -- Kazuho Oku
- AEAD and header encryption overhead in QUIC Kazuho Oku
- RE: AEAD and header encryption overhead in QUIC Nick Banks
- Re: AEAD and header encryption overhead in QUIC Matt Joras
- Re: AEAD and header encryption overhead in QUIC Mikkel Fahnøe Jørgensen
- Re: AEAD and header encryption overhead in QUIC Kazuho Oku
- Re: AEAD and header encryption overhead in QUIC Matt Joras
- Re: AEAD and header encryption overhead in QUIC Kazuho Oku