Re: Proposal to replace ACK block count with ACK length

[Eric Rescorla <[e-mail]>]

On Fri, Jun 15, 2018 at 6:46 PM, Marten Seemann <[e-mail]>
wrote:

> This proposal increases the size of the ACK frame by 1 byte in the common
> case (less than 63 ACK ranges), since the ACK length field here always
> consumes 2 bytes, whereas the ACK Block Count is a variable-length integer.
> Considering how much work we put into minimising the size of the frames,
> this feels like a step in the wrong direction.
>
> Regarding the processing cost, I agree with Dmitri. Handling an ACK frame
> requires looping over and making changes to a data structure that keeps
> track of sent packets. This is much more expensive than simply parsing a
> bunch of varints in the ACK frame. It seems unlikely that a multi-threaded
> packet parser would offer any real-world performance benefits.
>

I don't want to overstate the benefit here, but my point isn't that parsing
is expensive but that if you want to have a multithreaded packet processing
system, then it's nice to have a simpler data structure (the unparsed ACK
block) to hand to the ACK processing thread.

-Ekr



> On Sat, Jun 16, 2018 at 6:19 AM Martin Thomson <[e-mail]>
> wrote:
>
>> When we discussed this before, some people observed that this creates
>> a need to encode in two passes.  That's the trade-off here.  (Not
>> expressing an opinion.)
>> On Fri, Jun 15, 2018 at 3:51 PM Jana Iyengar <[e-mail]> wrote:
>> >
>> > 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]] 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
>> <dtikhonov@litespeedtech..com> 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.
>> >>
>> >>
>>
>>