IETF Logo Mail Archive

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

ianswett <notifications@github.com> Wed, 25 September 2019 01:26 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 D8323120047 for <quic-issues@ietfa.amsl.com>; Tue, 24 Sep 2019 18:26:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.495
X-Spam-Level:
X-Spam-Status: No, score=-6.495 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_IMAGE_ONLY_28=1.404, 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 1h52Lf2LDB5o for <quic-issues@ietfa.amsl.com>; Tue, 24 Sep 2019 18:26:49 -0700 (PDT)
Received: from out-20.smtp.github.com (out-20.smtp.github.com [192.30.252.203]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6AA7120033 for <quic-issues@ietf.org>; Tue, 24 Sep 2019 18:26:48 -0700 (PDT)
Received: from github-lowworker-a6a2749.va3-iad.github.net (github-lowworker-a6a2749.va3-iad.github.net [10.48.16.62]) by smtp.github.com (Postfix) with ESMTP id 34D9C8C11B7 for <quic-issues@ietf.org>; Tue, 24 Sep 2019 18:26:48 -0700 (PDT)
Date: Tue, 24 Sep 2019 18:26:48 -0700
From: ianswett <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK7O7KFWPT37GB364O53TABOREVBNHHB2TYBKQ@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/534811273@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_5d8ac25824b51_4d23fe7970cd960138922"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: ianswett
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/y3Zabo9br3xDjCwe3sOdqPw9e94>
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 01:26:51 -0000

I agree with @DavidSchinazi that I have never seen profiles indicating that AES with standard(ie: AES-NI or AVX) acceleration is more costly than sending UDP packets.

I'm confused about whether you have an amazingly fast UDP path or a very slow AES-GCM path, relatively speaking.  I've seen CPU profiles where 50% of CPU is spent sending UDP packets on two different platforms now, but I've never seen a profile where AES-GCM consumed more than sending UDP packets.

Can you share any measurements that might explain the large disparity between CPU profiles I've seen and you've seen or shed any light on why our experiences are so different?

-- 
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-534811273

v2.23.0 | Report a Bug | By Email