RE: Cost of parsing ACK frames in QUIC
Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com> Thu, 10 May 2018 15:12 UTC
Return-Path: <mikkelfj@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 A873612741D for <quic@ietfa.amsl.com>; Thu, 10 May 2018 08:12:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 k_6EKa0gNQAT for <quic@ietfa.amsl.com>; Thu, 10 May 2018 08:12:32 -0700 (PDT)
Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (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 027F8126CB6 for <quic@ietf.org>; Thu, 10 May 2018 08:12:32 -0700 (PDT)
Received: by mail-io0-x229.google.com with SMTP id e12-v6so3388989iob.8 for <quic@ietf.org>; Thu, 10 May 2018 08:12:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to; bh=Rj1k5fMdWuO4a8WPikkcfrX3ZsFXWZBTney5VyFuR8s=; b=Hb9ylRp/TVrPxgS6xiCT7GszbCW2nhV0H70d7CQN2gtSnZsCGCX2M4Y7eM7hEsuHdg I7+iXNEphGJTve98X1OT3HBw83HvZgdiPoQiGvAoz4X0OaETRm2P/jf5xU9mUQGC4rMH eFFK/pHmj1JmqHbRqDs7CnLcTI+9R9O4XbcTMg4tczvq2b8kOGi6i9VSmPjpZ6EbnHjC DppBWKzwbzI+jxtlMb19qxjJFMY6SwY/p8WPfDgJYCphM5r6oyKJOwcf5RRSKQo4Jn64 9hqgFEjdbaZyFi/OTx851SOXlqVC1qAu94XGcb51xuWbdfkBFEkXyq0qTZ9OSOW6oqXv U8Jg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to; bh=Rj1k5fMdWuO4a8WPikkcfrX3ZsFXWZBTney5VyFuR8s=; b=crhFuuf9QIoxPVcWl6dirEsvDnSaq2d+Ji5tfnCHg6z3GW3DxL2I+qQ08b1o5VAWki hvzpJ2XvShZeJlCh8NAqyn4UWahSDW3JUWmG7XM98HpvEL7EDWENoecQyjhCknQFsPo1 rtxuVWtM8h8wTC3e9P7ETIWmwcs8ibXY9vPLv/LYlx3UJ0q9NiT5ffMZWomh51pPsDZZ wkt+JQLCUnyBEPDTMM3H12zV9IoJDDTcNbPz/aPcKmvxz5hiaQgdDWGVy6fJy3RDn1DF KjJvjnL89k0qhwrhrdFq6IMqZJjAxpdmQ1OX3kb5an2eHumKwYfppQiRQ/cK3e4PuZz6 6fxg==
X-Gm-Message-State: ALKqPwfUxY5uc4F0yX0n7HRfUUTAlNv0j5ktvlTT8c2V8iPZsX9N76SZ CjGDM/c+AY/XObF6jw2f4pn0quKhBbWEYBl63aM=
X-Google-Smtp-Source: AB8JxZoFHM9+iOERf/c4MHgTS9MLqGShbPkXWBIbaXZv4Iu+IQcVe+SRGz9dDO2ypGTF+d6vtr+u4yEaZV9OQ1gIOTE=
X-Received: by 2002:a6b:b60a:: with SMTP id g10-v6mr1835270iof.209.1525965151447; Thu, 10 May 2018 08:12:31 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Thu, 10 May 2018 08:12:30 -0700
From: Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>
In-Reply-To: <CAN1APdfFBRzrf5d2L2i5gtT3_aGUcu0Oi3NVX_UdempAzyq9Tw@mail.gmail.com>
References: <1F436ED13A22A246A59CA374CBC543998B64E65D@ORSMSX111.amr.corp.intel.com> <CAN1APdcfmAsM-CBGzFEicBWf6Ck2uRhOmoiooo7d3EPDTjwt7g@mail.gmail.com> <DM5PR2101MB0901149C9E14440DF9CEE269B3980@DM5PR2101MB0901.namprd21.prod.outlook.com> <CAN1APdfFBRzrf5d2L2i5gtT3_aGUcu0Oi3NVX_UdempAzyq9Tw@mail.gmail.com>
X-Mailer: Airmail (420)
MIME-Version: 1.0
Date: Thu, 10 May 2018 08:12:30 -0700
Message-ID: <CAN1APddSV6R2L2Fp-d4V1T0jZ1JqDfmHcTpgsYtUm3hyjEU44Q@mail.gmail.com>
Subject: RE: Cost of parsing ACK frames in QUIC
To: Nick Banks <nibanks@microsoft.com>, "Deval, Manasi" <manasi.deval@intel.com>, IETF QUIC WG <quic@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000cab119056bdb72c1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/5G70IKexv6byiMNtQT-MpYuQy2o>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
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, 10 May 2018 15:12:33 -0000
At least for ACK outside handshake, but you cannot feed unreliable data into your application, so generally you need a full packet validation. On 10 May 2018 at 16.52.10, Mikkel Fahnøe Jørgensen (mikkelfj@gmail.com) wrote: Yes, that would often be the case. On 10 May 2018 at 16.49.59, Nick Banks (nibanks@microsoft.com) wrote: I’m don’t agree that you need to make two passes on a packet when processing ACK frames. If you have successfully decrypted the packet and you got to the point of processing ACK frames, then any other error that would later encounter while processing the packet would likely be considered a protocol violation, would it not? If so, then you would terminate the entire connection. That being said, on the topic of being a bit more expensive to process ACK frames in general, QUIC has made a decision to generally prefer smaller wire encoding over CPU costs, where appropriate. If you have a suggestion to change the encoding that doesn’t increase the wire format cost, we could take a look at it. - Nick *From:* QUIC <quic-bounces@ietf.org> *On Behalf Of * Mikkel Fahnøe Jørgensen *Sent:* Thursday, May 10, 2018 7:44 AM *To:* Deval, Manasi <manasi.deval@intel.com>; IETF QUIC WG <quic@ietf.org> *Subject:* Re: Cost of parsing ACK frames in QUIC While this may be true, please note that QUIC also requires that the entire packet is valid before it does anything that modifies the state of the receiver. This means that you generally have to do two passes of the packet to ensure that the packet is valid. In the first pass you can then store data for the optimistic case of a single ACK frame. That said, arguments about fast(er) processing still apply, but it is no longer limited to only ACK frames. On 10 May 2018 at 16.25.50, Deval, Manasi (manasi.deval@intel.com) wrote: Hi All, The QUIC header definitions tend to use as few bits as possible by implementing the policy to use variable size fields. The result of this policy would be that each receiver needs to do a two part lookup to identify the field and this needs to be implemented serially in order to parse the whole frame time. For example, in a case where no packets were dropped, a sender may receive an ACK for a single block. If a code path were trying to determine the size of an ACK, they would have to read 8 fields to determine the size of ACK. A client only sees a few ACKs. Majority of the ACKs are seen on the server side. It would be good to simplify this scheme so ACK processing can be accelerated with SIMD instructions would be good. Thanks, Manasi
- Cost of parsing ACK frames in QUIC Deval, Manasi
- Re: Cost of parsing ACK frames in QUIC Mikkel Fahnøe Jørgensen
- RE: Cost of parsing ACK frames in QUIC Lubashev, Igor
- RE: Cost of parsing ACK frames in QUIC Nick Banks
- RE: Cost of parsing ACK frames in QUIC Mikkel Fahnøe Jørgensen
- RE: Cost of parsing ACK frames in QUIC Mikkel Fahnøe Jørgensen