Re: Proposal to replace ACK block count with ACK length

[Jana Iyengar <[e-mail]>]

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.
>
>