IETF Logo Mail Archive

Re: [quicwg/base-drafts] Handling of corrupt Retry packets (#3014)

Nick Banks <notifications@github.com> Wed, 25 September 2019 00:46 UTC

Return-Path: <noreply@github.com>
X-Original-To: quic-issues@ietfa.amsl.com
Delivered-To: quic-issues@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 011C412004C for <quic-issues@ietfa.amsl.com>; Tue, 24 Sep 2019 17:46:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.281
X-Spam-Level:
X-Spam-Status: No, score=-6.281 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_IMAGE_ONLY_24=1.618, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 DL_8uJMOyB8h for <quic-issues@ietfa.amsl.com>; Tue, 24 Sep 2019 17:46:38 -0700 (PDT)
Received: from out-23.smtp.github.com (out-23.smtp.github.com [192.30.252.206]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F910120033 for <quic-issues@ietf.org>; Tue, 24 Sep 2019 17:46:38 -0700 (PDT)
Received: from github-lowworker-275fa97.va3-iad.github.net (github-lowworker-275fa97.va3-iad.github.net [10.48.17.64]) by smtp.github.com (Postfix) with ESMTP id 7636D660DAF for <quic-issues@ietf.org>; Tue, 24 Sep 2019 17:46:37 -0700 (PDT)
Date: Tue, 24 Sep 2019 17:46:37 -0700
From: Nick Banks <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK6I24CRGH76RIDHTEN3S74X3EVBNHHB2TYBKQ@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3014/534802829@github.com>
In-Reply-To: <quicwg/base-drafts/issues/3014@github.com>
References: <quicwg/base-drafts/issues/3014@github.com>
Subject: Re: [quicwg/base-drafts] Handling of corrupt Retry packets (#3014)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5d8ab8ed674a4_22a83f80b9acd96413301"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: nibanks
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/jtmvNluIXnXTiTw41vlMHNikOl0>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <quic-issues.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic-issues/>
List-Post: <mailto:quic-issues@ietf.org>
List-Help: <mailto:quic-issues-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Sep 2019 00:46:40 -0000

> This assumes that the great majority of packet processing time is spent on cryptographic operations, and that has never been my personal experience.

That may be so when doing things at the HTTP layer. I have had completely the opposite experience with my QUIC only performance tests. Encryption/decryption is closer to 60% to 75% of the CPU. UDP is the next largest, but because we've done a lot of optimizations in this area it's not that much.

But for HW, it's a whole different story. There is nothing but read QUIC header, read token, write token, write UDP packet. Read/write token will be, by far, the CPU bottleneck.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3014#issuecomment-534802829

v2.46.0 | Report a Bug | By Email | System Status