Subject: [quicwg/base-drafts] Decoding Largest Acked and Reliability (#731)

From: Patrick McManus <[email-masked]>
Date: Mon, 14 Aug 2017 23:50:23 +0000 (UTC)

In an ACK frame largest acked is "A variable-sized unsigned value". The text doesn't give a lot of guidance on exactly how its determined (other than its size), but presumably it uses the algorithm from 5.8.. except 5.8 clearly doesn't exactly apply because the packet number defined by 5.8 is "used as part of a cryptographic nonce for packet encryption. " which largest acked is not.

In any event, assuming a similar algorithm we would decode by " finding the packet number value that is closest to the next expected packet.".. which in the case of largest ack might be "largest previously received largest ack + 1".

So far, that's editorial. But, as is the case with packet envelope numbers, its certainly possible to mis-decode the number.. especially when using small encodings and reorderings occur. (and this is especially true with acknowledgment information which is actually retransmitted, unlike the packet envelope numbers themselves).

If you mis-interpret an envelope packet number its no big deal - the crypto will fail and you'll drop the packet. But if you mis-interpret a largest acked field then you mark as acked the wrong data. Perhaps data that never arrived and will now never be re transmitted. And you don't have a reliable protocol anymore. :(

oops?

-- 
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/731

---

From: Martin Thomson <[email-masked]>
Date: Tue, 15 Aug 2017 00:41:12 +0000 (UTC)

Well, you could argue that you can know how the value is going to be decoded based on the largest value for largest acknowledged you have sent *and had acknowledged*.  That's somewhat disgusting though.

Throw this in the bucket for #644.

I tend to think that we're better off looking at integer coding more generally.  Finding an encoding that allows us to express the most common values efficiently would be great.  Then we don't have to use this nasty truncation thing.

-- 
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/731#issuecomment-322347045

---

From: Martin Thomson <[email-masked]>
Date: Tue, 15 Aug 2017 00:42:52 +0000 (UTC)

Actually, re-reading the section on ACK, I *think* that largest acknowledged isn't truncated.  if the number doesn't fit in N bits, then you need to use the next size up.

-- 
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/731#issuecomment-322347250

---

From: Patrick McManus <[email-masked]>
Date: Tue, 15 Aug 2017 00:54:06 +0000 (UTC)

what is the point of 8 and 16 bit formats for largest acked if it isn't truncable (given random 31 bit initial packet number)?

-- 
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/731#issuecomment-322348693

---

From: Martin Thomson <[email-masked]>
Date: Tue, 15 Aug 2017 00:57:58 +0000 (UTC)

An excellent question.  Though I will observe that the 8- and 16- bit variants were present prior to the introduction of randomization.

-- 
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/731#issuecomment-322349180

---

From: ianswett <[email-masked]>
Date: Tue, 15 Aug 2017 02:04:53 +0000 (UTC)

Yes, the intent was for the largest ack not to be truncated, as Martin observed.

The benefits of 8 and 16 bit formats are for short connections(realistically, most connections Chrome completes fit in 8 bits) and for consistency with other numerical formats that are 8/16/32/64.

As Martin mentioned, with randomization, 8 and 16 bit formats seem useless.  That being said, I'm not sure what the value of randomizing over 32 bits is given QUIC has 8 bytes of entropy in the connection id?

-- 
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/731#issuecomment-322357192

---

From: Martin Thomson <[email-masked]>
Date: Mon, 14 Aug 2017 19:16:20 -0700

I thought that it was grease.

-- 
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/731#issuecomment-322358676

---

From: Patrick McManus <[email-masked]>
Date: Mon, 14 Aug 2017 19:27:01 -0700

@ianswett good news I guess. I'm not sure trunc could be done correctly give non-cumulative sacks, reordering, etc..

issue #35 cites ossification as the motivation for random.

There is an obvious mechanism of normalizing them against the first packet 'wireshark tcp style' to encode against pn=0 but I don't think its worth it...

-- 
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/731#issuecomment-322360339

---

From: Patrick McManus <[email-masked]>
Date: Tue, 15 Aug 2017 02:27:25 +0000 (UTC)

might be able to call this editorial

-- 
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/731#issuecomment-322360392

---

From: ianswett <[email-masked]>
Date: Mon, 14 Aug 2017 19:28:29 -0700

Also, once we start changing connection IDs, we may want to have multiple ack frames in a single packet because the largest acked of each will be so far from each other, at which point I think absolute is the only sane way to go.

-- 
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/731#issuecomment-322360537

---

From: ianswett <[email-masked]>
Date: Tue, 15 Aug 2017 11:30:50 +0000 (UTC)

Yes, it was grease Martin.  I keep forgetting the long packet format is always a 4 byte packet number, unlike gQUIC which has variable length for everything.

So given that, 4 and 8 make sense.  Other values don't seem to.

-- 
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/731#issuecomment-322443560

---

From: Martin Thomson <[email-masked]>
Date: Wed, 16 Aug 2017 01:59:15 +0000 (UTC)

I'm not going to "fix" that particular error right now.  We have a task to take a good hard look at the encoding of the ACK frame in #644 and I'd rather we do that than piecemeal fix little errors.  In the meantime, we should address the confusion problem @mcmanus had.  I'll open an issue to track the size 1 and size 2 ACK frames so we don't lose it.

-- 
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/731#issuecomment-322642034