Re: Proposal to replace ACK block count with ACK length

[Jana Iyengar <[e-mail]>]

I don't have a strong opinion on this. I'm certainly not opposed to it.
Does anyone have a strong opposition?

On Fri, Jun 15, 2018 at 3:10 PM Praveen Balasubramanian <[e-mail]>
wrote:

> I agree as well since this can help reduce per packet processing overhead.
> ACKs are going to be the second most common frame type so no objections to
> special casing.
>
>
>
> *From:* QUIC [mailto:[e-mail]] *On Behalf Of *Eric Rescorla
> *Sent:* Friday, June 15, 2018 9:11 AM
> *To:* Deval, Manasi <[e-mail]>
> *Cc:* Jana Iyengar <[e-mail]>; QUIC WG <[e-mail]>
> *Subject:* Re: Proposal to replace ACK block count with ACK length
>
>
>
> 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] <quic-bounces@ietf..org>] *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.
>
>
>