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 9B72112EB00 for ; Thu, 10 May 2018 07:52:13 -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 dsvqZAsjBxQM for ; Thu, 10 May 2018 07:52:11 -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 B62F11241FC for ; Thu, 10 May 2018 07:52:11 -0700 (PDT) Received: by mail-io0-x229.google.com with SMTP id a10-v6so3312620ioc.9 for ; Thu, 10 May 2018 07:52:11 -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=H2KnolZP2sKh9BLhEDc96pIpQQDzBTO0QQ1I9ssTL1M=; b=JRxXccWjlYJfCC0XDV0L/dTTeWDG3v8UY4PwgNzAupVNeHSisbbSUSB/SaG5O+eDPY r926E6hFn50TkocVcGnhUoODPWFKUfdPJ5cifbb5r55S8zvwgZ/uX7IGKr2bu7Xt7ofa +lz9ITsiOE3XGplUAOmC9GdkIH89PyVRrvGD7Nct/e7CmDv9GEF3xhhYhXbnmsMrPUMx XbNcjmGzyM5SbUQvQ8s/q2m9x+L+Pkcvm7zKbchRf7wpo57RC/pGdR5OgPtlQrOrRGdb A8LnTZfQd2cp5XBcz7iFGTxaGubNbUDr8IhzfM2bEBL4CBlzxZLGFq/TnR7sBd+4OXYu nLPg== 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=H2KnolZP2sKh9BLhEDc96pIpQQDzBTO0QQ1I9ssTL1M=; b=sEWxwHaaGAn79xDPozdL4lGbFNPoWV4nxhsCMd8oTecQqeduYxubHhMgMD9Fwzikbw D/LRpGUoFdVQ7tQFRagrM8MV0zNiRp9dQvRlW7UqXqTRrVNm1gyQb9Hd9mUKKCfyuAny yAuyd2Eu16NhcF6+abPyl6gxvOxzxviocv3AC+q1YYZaawmCrTTkRgAHHuHoFHAZ/cVQ dpVELI6x8reEqXWV/eMjbOtqBd+d5HrEJF5i4JbMzK5KycrF+ZHB/W31BE8itMj9J4m/ I6Tl5Xgv1B+EuC6H3yeasQ5Eiw6h85S/vfKisx7rP/u/WvOpilKveBNQU7GKyobghori XY5g== X-Gm-Message-State: ALKqPwfvnUvGRhuWgDh3KJ5pmYUwwFjUs4UCBilQShULxahiNtlwrP0R PP8X3i9FI1Pz54tb0VmZmWisdHbob/wBtqr1BpE= X-Google-Smtp-Source: AB8JxZrAvjXZFz8gW2FPcxzyF4FAhWi4i3tXTM1uAQejoutB/VL7Zsl+cEQzZa24rJmmyaA8JNavdmn9jgQmWxPvDyY= X-Received: by 2002:a6b:b60a:: with SMTP id g10-v6mr1745539iof.209.1525963931069; Thu, 10 May 2018 07:52:11 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Thu, 10 May 2018 07:52:10 -0700 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: <1F436ED13A22A246A59CA374CBC543998B64E65D@ORSMSX111.amr.corp.intel.com> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Thu, 10 May 2018 07:52:10 -0700 Message-ID: Subject: RE: Cost of parsing ACK frames in QUIC To: Nick Banks , "Deval, Manasi" , IETF QUIC WG Content-Type: multipart/alternative; boundary="0000000000000d33fc056bdb2a10" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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: Thu, 10 May 2018 14:52:14 -0000 --0000000000000d33fc056bdb2a10 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Yes, that would often be the case. On 10 May 2018 at 16.49.59, Nick Banks (nibanks@microsoft.com) wrote: I=E2=80=99m don=E2=80=99t agree that you need to make two passes on a packe= t 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=E2=80=99t increase the wire format cost, = we could take a look at it. - Nick *From:* QUIC *On Behalf Of * Mikkel Fahn=C3=B8e J= =C3=B8rgensen *Sent:* Thursday, May 10, 2018 7:44 AM *To:* Deval, Manasi ; IETF QUIC WG *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 --0000000000000d33fc056bdb2a10 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = Yes, that would ofte= n be the case.


On 10 May 2018 at 16.49.59, Nick Bank= s (nibanks@microsoft.com) wrot= e:

I=E2=80=99m don=E2=80=99t agree that you need to mak= e two passes on a packet when processing ACK frames. If you have successful= ly 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, wou= ld it not? If so, then you would terminate the entire connection.

=C2=A0

That being said, on the topic of being a bit more ex= pensive to process ACK frames in general, QUIC has made a decision to gener= ally prefer smaller wire encoding over CPU costs, where appropriate. If you= have a suggestion to change the encoding that doesn=E2=80=99t increase the wire format cost, we could take a look a= t it.

=C2=A0

- Nick

=C2=A0

From: QUIC <quic-bounces@ietf.org> On Behalf Of Mikkel Fahn=C3=B8e J=C3=B8rgensen
Sent: Thursday, May 10, 2018 7:44 AM
To: Deval, Manasi <mana= si.deval@intel.com>; IETF QUIC WG <quic@ietf.org>
Subject: Re: Cost of parsing ACK frames in QUIC

=C2=A0

While this may be true, please note that QUIC als= o requires that the entire packet is valid before it does anything that mod= ifies the state of the receiver.

=C2=A0

This means that you generally have to do two pass= es 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.

=C2=A0

That said, arguments about fast(er) processing st= ill apply, but it is no longer limited to only ACK frames.

=C2=A0

=C2=A0

On 10 May 2018 at 16.25.50, Deval, Manasi (manasi.deval@intel.com) wrote:

Hi All,

=C2=A0

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 se= rially in order to parse the whole frame time.

=C2=A0

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.

=C2=A0

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 b= e good.

=C2=A0

Thanks,

Manasi

--0000000000000d33fc056bdb2a10--