Re: Unified ACK frame encoding

[Martin Thomson <[e-mail]>]

On Fri, Aug 10, 2018 at 6:15 AM Ian Swett <[e-mail]> wrote:
> There are a few things I like about this proposal:
> 1) It makes ECN and ACK_ECN either the same(or more similar)
> 2) As Kazuho said, it provides more precise feedback about which packets were marked, which avoids some edge cases we've had to write up in the current text around ack loss and being unsure of exactly when recovery is exited.
> 3) It doesn't get more expensive as the connection goes on.  This is an unfortunate property of the current design.
>
> I find Jana's variation on this particularly interesting, because if ECN isn't negotiated, I don't think there a reason to add any overhead.  From personal experience, if you find a form of feedback valuable(whether it's ECN or timestamps for one-way-delay), then you're happy to consume a few extra bytes to get better feedback.  If the extra information isn't useful for whatever reason, it's just wasted bytes.

OK, 4 values is definitely easier to reason about.  Merging ECT(0) and
ECT(1) into the same bucket is easy as long as we're OK with that.
The simpler encoding is easier to describe and write code for, and we
can just tolerate (or reject) two adjacent ranges of the same type,
just as we might tolerate (or reject) a trailing gap.

> So overall this seems like an improvement we should do, but I'd prefer a variant that doesn't increase the ACK frame size when ECN is disabled or there are no ECN marks to report.  FYI, if we need to steal a bit from the number of ack blocks, I'm ok with that since I expect more than 32 ack blocks to be very rare.

This is very close to a variant I suggested on the issue, which we
agreed pretty quickly wasn't great.  You can create two ACK frames,
one with the full expressiveness, and another that has the potential
to encode the ECN information.  Call the second one ACK_ECN...

I'm not convinced that optimizing for the awkward space between 16 and
64 is worth the extra complexity of a variant encoding of the frame.
There are other ways to optimize for the cost of that occasional octet
that seem like they would be more fruitful (like truncating ACK frames
more aggressively).