Re: Proposal to replace ACK block count with ACK length

[Eric Rescorla <[e-mail]>]

I agree with Manasi here. This change would allow ack frame parsing to be
more self-contained, which is an advantage for the parser and also
potentially for parallelism (because you can quickly find the frame and
then process it in parallel).

-Ekr


On Mon, Jun 11, 2018 at 5:22 PM, Deval, Manasi <[e-mail]>
wrote:

> In general, varints require some specific logic for parsing. To skip over
> any header, I have to read every single varint. As the code sees Stream and
> ACK headers most frequently, that is my focus.  The Stream frame has a
> length in its third field.
>
>
>
> ACK parsing, however, needs 6 + 2*num_blocks reads to identify length.
> There are two reads each for ‘largest acknowledged’, ‘ACK delay’ and ‘ACK
> block count’. The pain point is the total number of cycles parse an ACK. If
> I am processing 10M pps, where 10% - 30% of the packets have a piggybacked
> ACK, these cycles becomes a significant bottleneck.
>
>
>
> Thanks,
>
> Manasi
>
>
>
>
>
>
>
> *From:* QUIC [mailto:[e-mail]] *On Behalf Of *Jana Iyengar
> *Sent:* Monday, June 11, 2018 3:11 PM
> *To:* Deval, Manasi <[e-mail]>; QUIC WG <[e-mail]>
> *Subject:* Re: Proposal to replace ACK block count with ACK length
>
>
>
> You're right that we no longer have the ability to skip an ACK frame, and
> this crept in when we moved to varints.
>
> I believe your problem though is generally true of most frames not just
> ACKs, since ids, packet numbers, and numbers in all frames are now all
> varints. To skip any frame, you'll need to parse the varint fields in those
> frames. If you have logic to process and skip varints, then skipping the
> ack block section is merely repeating this operation (2*num_block+1) times.
> Do you see specific value in skipping ACK frames over the other control
> frames?
>
>
>
>
>
> On Mon, Jun 11, 2018 at 8:43 AM Dmitri Tikhonov <
> [e-mail]> wrote:
>
> On Mon, Jun 11, 2018 at 03:33:35PM +0000, Deval, Manasi wrote:
> > -        Moving the ACK length to the front of the ACK allows the
> >          flexibility of either reading the entire ACK or reading the
> >          first 16 bits and skipping over the length. This is a useful
> >          feature for the case where ACK processing is split into
> >          multiple layers. Depending on the processor this is run on,
> >          there are different advantages -
>
> Just a note.  In my experience, the cost of parsing an ACK frame is
> negligible compared to the cost of processing an ACK frame: that is,
> poking at various memory locations to discard newly ACKed packets.
>
>   - Dmitri.
>
>