Re: [quicwg/base-drafts] Improve ACK_ECN frame encoding (e.g., use bit-vector) (#1439)

[Kazuho Oku <[e-mail]>]

@martinthomson 
> I'm not sure that this is simpler.

Yeah. What I was trying to say by stating that the ACK frame becomes simpler is that we can eliminate the distinction between "first ack block", "additional ack block", "gap" by having type assigned to each block.

> You could save a whole bit by making it impossible to send two blocks of the same type in a row and encoding the mode as `n = (next_mode - last_mode + 4) % 5` and decoding with `next_mode = (last_mode + n + 1) % 5`.

That definitely works. I had some hesitation against making the interpretation of the mode depend on the mode of the previous block, but that might be fine considering the fact that where the block begins depends on the bit pattern of the previous block (which is a varint).

> The cost here is that a single ECN-CE-marked datagram costs 3 octets to encode. The benefit is that you have one ACK frame; and if you don't have ECN markings, the overhead is limited to a slightly less efficient encoding of longer sequences of packets (>16 with my hack).

Yes. And my argument regarding the cost is that spending 3 octets should be fine, because we spend the same amount to express a gap. If it is not fine, we should reconsider how we express gaps.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1439#issuecomment-397162080