RE: Cost of parsing ACK frames in QUIC

Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com> Thu, 10 May 2018 14:52 UTC

From: Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>
In-Reply-To: <DM5PR2101MB0901149C9E14440DF9CEE269B3980@DM5PR2101MB0901.namprd21.prod.outlook.com>
References: <1F436ED13A22A246A59CA374CBC543998B64E65D@ORSMSX111.amr.corp.intel.com> <CAN1APdcfmAsM-CBGzFEicBWf6Ck2uRhOmoiooo7d3EPDTjwt7g@mail.gmail.com> <DM5PR2101MB0901149C9E14440DF9CEE269B3980@DM5PR2101MB0901.namprd21.prod.outlook.com>
MIME-Version: 1.0
Date: Thu, 10 May 2018 07:52:10 -0700
Message-ID: <CAN1APdfFBRzrf5d2L2i5gtT3_aGUcu0Oi3NVX_UdempAzyq9Tw@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="0000000000000d33fc056bdb2a10"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/sOf1uLNnPA1ss_yXMCkT9kzm4L0>
Precedence: list

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