Re: Proposal to replace ACK block count with ACK length

[Kazuho Oku <[e-mail]>]

2018-06-16 8:19 GMT+09:00 Martin Thomson <[e-mail]>:
> 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.)

I am not sure if we have that trade-off.

ACK frame as currently defined needs to be generated in two-pass
because the size of the ACK Block Count field depends on the number of
blocks you would actually emit, unless the QUIC stack maintains the
number of gaps in the ACK queue.

And I think that the proposed change would be fine because it does not
necessary increase the size of the ACK frame, if we remove ACK Block
Count field in exchange.

Instead of relying on the field, a receiver of the ACK frame can read
blocks until it consumes the number of bytes specified by the length
of the frame.

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



-- 
Kazuho Oku