Subject: [quicwg/base-drafts] Outstanding packets and packet number size (#286)

From: Martin Thomson <[email-masked]>
Date: Thu, 09 Feb 2017 23:51:06 -0800

The text for packet number size calculation says:

> a QUIC sender MUST NOT have more than 2^(packet_number_size - 2) in flight

What it means to be "in flight" is not defined.  It seems like it might mean unacknowledged, not including packets that were marked as "lost" by the recovery algorithm.  The difference between the current packet number and the highest acknowledged packet number might also work.

The more that I think about this, the more that I'm convinced that this is made up of 90% fudge.  Neither of the above definitions for "in flight" is perfect and the constant (4) is pure fudge.

What we might ideally want to ask before determining how big the packet number encoding needs to be is how far out of order a packet could possibly get during transit - and at what point we consider excessive reordering to be considered loss.  If we assume either definition, the current mandate assumes that we want to recover from delay of 4 times the RTT (with the first definition, add four times the reordering threshold).

That seems excessive.  Given that we should be getting at least an ACK per RTT in these cases, that much delay will likely result in retransmission several times over unless all of the ACK packets are similarly delayed.

While we might make some recommendations, "MUST" doesn't seem correct.  I suspect that we need data on reordering (or packet delays) under real-world conditions before we could make a better recommendation.

I think that we need to make the following changes: 
1. define "in flight" (or use a new definition based on RTT and the reordering threshold)
2. make this a recommendation rather than a requirement
3. update the values in the recommendation based on data
4. maybe advise being conservative: spending an extra byte or two occasionally might be wise if it means avoiding packets being lost

This issue should wait for the outcome of the header discussions, it could become moot.

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

---

From: Martin Thomson <[email-masked]>
Date: Fri, 10 Feb 2017 00:13:15 -0800

Alternative definition that might be even better: the difference between this packet and the lowest packet number that has neither been acknowledged nor declared lost.

-- 
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/286#issuecomment-278883235

---

From: Ryan Hamilton <[email-masked]>
Date: Fri, 10 Feb 2017 10:27:16 -0800

"Alternative definition that might be even better: the difference between this packet and the lowest packet number that has neither been acknowledged nor declared lost."

That sounds like a good definition to me. It's simple and clear.

-- 
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/286#issuecomment-279025165

---

From: ianswett <[email-masked]>
Date: Fri, 10 Feb 2017 13:27:21 -0800

In this case, using in flight would be wrong if packet numbers were skipped.

However, I think we would prefer "the difference between this packet and the largest acknowledged packet."  We may have smaller packets that are unacknowledged, but the algorithm only relies upon the largest received packet.  I don't think there's a need to talk about packets declared lost in this case, since we're abandoning using in flight in this context.

-- 
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/286#issuecomment-279070413

---

From: ianswett <[email-masked]>
Date: Fri, 10 Feb 2017 13:29:10 -0800

Also, this doesn't really become moot even if we adopt a fixed packet number length.  That just means we have a fixed maximum on the gap between the packet currently being sent and the largest acked.

-- 
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/286#issuecomment-279070807

---

From: janaiyengar <[email-masked]>
Date: Fri, 17 Feb 2017 09:41:37 -0800

Closed #286 via #299.

-- 
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/286#event-967304514