Subject: [quicwg/base-drafts] Praveen's WGLC comments (#3919)

From: ianswett <[email-masked]>
Date: Thu, 16 Jul 2020 12:19:35 -0700

>From https://mailarchive.ietf.org/arch/msg/quic/_KeDg0RMQqP5epdYQdFb0M7MJ5s/, minus the question of limiting bursts, which is in Issue #3918

Section 2

" are not acknowledged, declared lost, or abandoned along with old keys." -->  are not acknowledged, declared lost, or discarded along with old keys."

Discarding is the term used in the rest of the doc notably in section 2.4. I see some reference to "abandon packets" in the transport draft as well. Would be good to use the same term for consistency everywhere.

Section 4.4. 

 "does not allow any acked packet to be reneged" --> "does not allow any acknowledged packet to be reneged"

Section 4.7

"QUIC uses a probe timeout (see Section 6.2)," --> "QUIC uses a Probe Timeout (PTO) (see Section 6.2),"

Section 5.2 "If the path's actual RTT increases, the min_rtt will not adapt to it, allowing future RTT samples that are smaller than the  new RTT be included in smoothed_rtt."

Would it safer to reset min_rtt after persistent congestion is declared. This is important so we can adapt to a consistent spike in RTT as a result of a path change.

Section 6.1.1

"Algorithms that increase the reordering threshold after spuriously detecting losses, such as TCP-NCR [RFC4653], have proven to be useful in TCP and are expected to at least as useful in QUIC."

It might be better to refer to RACK here which has an optional feature to increase reorder threshold in time. I don't know of any major implementations that do TCP-NCR but maybe I am mistaken.

Section 6.2.1

"time threshold Section 6.1.2" --> time threshold (Section 6.1.2)

“The life of a connection that is experiencing consecutive PTOs is limited by the endpoint's idle timeout.”

Is there any specification of recommended values for idle timeout? Any values lower than 9 seconds could adversely impact preserving of connectivity during VM live migration.

Section 6.2.4

"If the sender wants to elicit a faster acknowledgement on PTO, it can skip a packet number to eliminate the ack delay."

This adds some unnecessary complexity. Given that endpoint MAY send two full-sized datagrams, isn't that a better technique than skipping packet numbers?

Section 7.8

"The congestion period is calculated as the time between the oldest and newest lost packets: (3 - 0) = 3." --> "The congestion period is calculated as the sent time difference between the oldest and newest lost packets: (3 - 0) = 3."

It might be worth noting that persistent congestion can be declared without sending a PTO. Particularly because the example assumes PTOs. In the case where app kept on periodically sending new data and no ACKs came back for the threshold and then an ACK came back and declared all packets sent before it as lost.

Section 8.2

"Endpoints can use PADDING frames or bundle acknowledgments with other frames to reduce leaked information."
A reminder should be added here that PADDING counts towards in-flight so there is a possible impact on performance.

Section B.8

The function AreAllPacketsLost does not have any pseudocode.

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

---

From: Kazu Yamamoto <[email-masked]>
Date: Thu, 16 Jul 2020 19:14:53 -0700

@ianswett The last item is pointed out in #3288. As I wrote in #3288, @tatsuhiro-t suggested an example implementation. If you think it is reasonable, I will make a PR.

-- 
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/3919#issuecomment-659791103

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 21 Jul 2020 13:29:26 -0700

I've addressed the editorial bits in #3928. The rest are addressed below.

- We don't have a recommended value for Idle timeout, but it the [transport spec](https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#section-10.1) states the following:
```
To avoid excessively small idle timeout periods, endpoints MUST increase the
idle timeout period to be at least three times the current Probe Timeout (PTO).
```
That said, the peer's `max_idle_timeout` is known to both sides. If you find that the peer's timeout is too short for your purposes, you can keep the connection alive through PINGs.

- On faster acknowledgement when PTO: yes, sending two packets works just fine. Skipping packet numbers is not something you need to do -- so the additional complexity concern is only for those who want to go do it -- it's just something that an implementation can do to get an immediate ack anytime in the connection.

- On PTOs and persistent congestion, there's text at the top of the section that calls this out explicitly:
```
Commonly, this can be established by consecutive PTOs, but since the PTO timer
is reset when a new ack-eliciting packet is sent, an explicit duration must be used
to account for those cases where PTOs do not occur or are substantially delayed.
```
Nevertheless, I've added a sentence at the end of the example description.

- AreAllPacketsLost is in #3288.

-- 
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/3919#issuecomment-662089620

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 21 Jul 2020 15:14:31 -0700

Marking this editorial, since the design one moved out.

-- 
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/3919#issuecomment-662134046

---

From: Jana Iyengar <[email-masked]>
Date: Wed, 22 Jul 2020 19:00:20 -0700

Closed #3919 via #3928.

-- 
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/3919#event-3578161253