Subject: [quicwg/base-drafts] pto_count should be reset when dropping a packet number space (#3272)

From: Marten Seemann <[email-masked]>
Date: Sat, 23 Nov 2019 03:43:30 -0800

`pto_count` should be reset to 0 when a packet number space is dropped. I'd argue that this is the consistent thing to do, because when we drop a packet number space, we implicitely acknowledge all outstanding packets in that space (and remove them from `bytes_in_flight`).

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

---

From: Jana Iyengar <[email-masked]>
Date: Sat, 23 Nov 2019 06:33:55 -0800

I think this is alright. It should happen anyway, since receiving an ACK
should be the common case.

On Sat, Nov 23, 2019, 7:43 PM Marten Seemann <[email-masked]>
wrote:

> pto_count should be reset to 0 when a packet number space is dropped. I'd
> argue that this is the consistent thing to do, because when we drop a
> packet number space, we implicitely acknowledge all outstanding packets in
> that space (and remove them from bytes_in_flight).
>
> —
> Reply to this email directly, view it on GitHub
> <https://github.com/quicwg/base-drafts/issues/3272?email_source=notifications&email_token=ACUOBVDKY7DEHZVVBTYYM7TQVEJODA5CNFSM4JQZ2L6KYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4H3RXQUQ>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/ACUOBVBBCAAP2HEQKL55DRTQVEJODANCNFSM4JQZ2L6A>
> .
>

-- 
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/3272#issuecomment-557802728

---

From: ianswett <[email-masked]>
Date: Sat, 23 Nov 2019 11:11:19 -0800

I also tend to think this is Ok.  Importantly, if you don't get any ACKs, you also have no RTT samples, and in that case, continuing to backoff the PTO is very possibly the right thing to do.

-- 
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/3272#issuecomment-557824698

---

From: Kazuho Oku <[email-masked]>
Date: Sun, 24 Nov 2019 20:00:10 -0800

Maybe I'm confused, but shouldn't `pto_count` be per-PN-space, now that PTO is per-PN-space (#3066)?

-- 
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/3272#issuecomment-557977001

---

From: ianswett <[email-masked]>
Date: Tue, 26 Nov 2019 21:48:05 -0800

I believe the simplest way to ensure QUIC isn't overly aggressive during the handshake and to encourage packet coalescing is to specify pto_count on a connection scope, similar to the rtt variables.  I considered making pto_count per-PN space, but that doesn't ensure quite the same exponential backoff properties and I don't believe it's necessary.

-- 
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/3272#issuecomment-558939818

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 28 Nov 2019 03:10:23 -0800

> I believe the simplest way to ensure QUIC isn't overly aggressive during the handshake and to encourage packet coalescing is to specify pto_count on a connection scope, similar to the rtt variables.

I think we agree that PTO during handshake should be _as aggressive as_ after the handshake. However, I am starting to wonder if the current spec. actually works that way.

Consider the case when the server responds to ClientHello. It would be sending Initial, Handshake, and 1-RTT packet at the same time. Then, when those QUIC packets gets lost, the loss timer would be invoked three times, resulting in pto_count set to 3. Is that the intended behavior? I think in such case, pto_count should become one, after the PTO timers of each epoch is triggered.

Therefore, to me, the correct logic seems to be:
* have pto_count for each epoch
* every time the per-epoch PTO timer is triggered, increment the per-epoch pto_count by 1
* when an ACK is being received on *any* epoch, reset pto_count of all the epochs

-- 
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/3272#issuecomment-559450820

---

From: Jana Iyengar <[email-masked]>
Date: Thu, 28 Nov 2019 10:23:00 -0800

@kazuho: you make a good point. I don't think this is orthogonal to the original issue, I think it's very much related. In addition to what you note, you would also need to use the per-epoch counter for determining how long to set the timer.

This is going to be imperfect or ugly or both. If we use a single pto_count, we'll have duplicate counts. If we use separate pto_counts, we'll have to reconcile different epochs having varying counts.

I think the behavior we're looking for is (i) use a separate pto_count per epoch, (ii) use the max of all pto_counts when setting the timer for any PN space, (iii) reset all pto_counts when an ACK is received for any epoch. 

This isn't great, and it is imperfect -- you can end up being more aggressive than with a single count. But I think it's good enough.

-- 
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/3272#issuecomment-559578665

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 28 Nov 2019 16:02:07 -0800

@janaiyengar 
> This isn't great, and it is imperfect -- you can end up being more aggressive than with a single count. But I think it's good enough.

The logic you describe sounds fine to me (apparently I missed (ii)), it would make the PTO behavior during handshake _as aggressive as_ after the handshake. I cannot see when it would be more aggressive than that, and I think it's better than "imperfect but good enough."

-- 
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/3272#issuecomment-559621651