Subject: [quicwg/base-drafts] Ack Delay and TLP (#1796)

From: ianswett <[email-masked]>
Date: Tue, 25 Sep 2018 07:25:09 -0700

Fixes some remaining issues now that QUIC recommends sending an ACK every two packets, mostly involving reverting to the TCP style TLP calculation.

I wrote this based on 'two full-sized packets' equalling a fixed 2400 bytes.  QUIC could send immediate acks for non-full-sized packets, but that's not what TCP does.  I could base it on the connection's packet size, but that requires the receiver to monitor the sender's max packet size, which made me a bit concerned?

Advice on how to ensure sender and receiver agree on packet size would be appreciated.
You can view, comment on, or merge this pull request online at:

  https://github.com/quicwg/base-drafts/pull/1796

-- Commit Summary --

  * Ack Delay and TLP

-- File Changes --

    M draft-ietf-quic-recovery.md (50)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/1796.patch
https://github.com/quicwg/base-drafts/pull/1796.diff

-- 
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/pull/1796

---

From: Nick Banks <[email-masked]>
Date: Tue, 25 Sep 2018 07:43:08 -0700

nibanks commented on this pull request.

> @@ -834,8 +827,13 @@ Pseudocode for SetLossDetectionTimer follows:
       timeout = timeout * (2 ^ rto_count)
       if (tlp_count < kMaxTLPs):
         // Tail Loss Probe
-        tlp_timeout = max(1.5 * smoothed_rtt
-                           + max_ack_delay, kMinTLPTimeout)
+        if (bytes_in_flight < 2400):
+          // Less than one full-sized packet in flight.
+          tlp_timeout = max(1.5 * smoothed_rtt

Should the comment here be `Less than two full-sized packets in flight`?

> @@ -834,8 +827,13 @@ Pseudocode for SetLossDetectionTimer follows:
       timeout = timeout * (2 ^ rto_count)
       if (tlp_count < kMaxTLPs):
         // Tail Loss Probe
-        tlp_timeout = max(1.5 * smoothed_rtt
-                           + max_ack_delay, kMinTLPTimeout)
+        if (bytes_in_flight < 2400):
+          // Less than one full-sized packet in flight.
+          tlp_timeout = max(1.5 * smoothed_rtt
+                              + max_ack_delay, kMinTLPTimeout)
+        else:
+          tlp_timeout = max(1.5 * smoothed_rtt,

I believe the `1.5` here should be `2` according to the text you have above.

> @@ -365,7 +352,11 @@ receiver.
 The timer duration, or Probe Timeout (PTO), is set based on the following
 conditions:
 
-* PTO SHOULD be scheduled for max(1.5*SRTT+MaxAckDelay, kMinTLPTimeout)
+* If less than 2400 bytes are in flight, PTO SHOULD be scheduled for

Having this somewhat magic number here just feels weird. This is the number of bytes 'we, locally' have in flight right? So don't we know our current sending MTU? Can't it just be two times that?

-- 
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/pull/1796#pullrequestreview-158577350

---

From: ianswett <[email-masked]>
Date: Tue, 25 Sep 2018 09:50:45 -0700

@ianswett pushed 1 commit.

33a6b56  Update draft-ietf-quic-recovery.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1796/files/1245368fbc90cd5c3a873693c82a8e20ec29811d..33a6b560727cac89304877faa942dfeaa028c657

---

From: ianswett <[email-masked]>
Date: Tue, 25 Sep 2018 16:52:23 +0000 (UTC)

ianswett commented on this pull request.

Should I move to 2* kMaxDatagramSize?

Yes, but the receiver needs to know the current.  Should I reference kMaxDatagramSize and call that close enough?  I'm fairly concerned that if that changes over the course of the connection, the sender and receiver will not act predictably.

-- 
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/pull/1796#pullrequestreview-158637248

---

From: Nick Banks <[email-masked]>
Date: Tue, 25 Sep 2018 10:00:28 -0700

So, is the receiver acknowledging based on byte count or packet count? I thought it was packet count. If so, then it seems to reason, the sender should do the same here.

-- 
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/pull/1796#discussion_r220272371

---

From: ianswett <[email-masked]>
Date: Tue, 25 Sep 2018 10:21:56 -0700

My understanding is that TCP waits for 2 full-sized packets, so I was trying to specify something similar to that in bytes.  The issue here becomes what constitutes a full-sized packet if the packet size changes?  Maybe keeping a max received packet size is reasonable?

We can add a packet count, but it's yet another variable to track and I don't think receiving two tiny packets would cause an immediate ACK in TCP, so I wouldn't expect it to in QUIC.

-- 
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/pull/1796#discussion_r220280495

---

From: ianswett <[email-masked]>
Date: Tue, 25 Sep 2018 20:45:05 +0000 (UTC)

0c4826f  Use 2*kMaxDatagramSize

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1796/files/33a6b560727cac89304877faa942dfeaa028c657..0c4826f48f682fd856cd6581a9bafdf6216fd736

---

From: Rui Paulo <[email-masked]>
Date: Sat, 29 Sep 2018 14:45:16 -0700

Probably unrelated to this PR but should kMaxDatagramSize really be a constant?  If a sender has performed PMTUD then it could be higher or lower.  If we change it to a non-constant then it would also take into account max_packet_size from the TPs.

-- 
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/pull/1796#issuecomment-425677536

---

From: ianswett <[email-masked]>
Date: Sun, 30 Sep 2018 18:14:48 -0700

That is definitely a potential issue with this PR.

The nice aspect of calculating this in bytes is it's already something the sender has to track.  However, I suspect a slightly more robust approach is for the sender to count number of 'full-sized'(>=1200 byte) packets with a separate counter?  I'm happy to rewrite the PR indicating that, but would like to hear some input from you and others.

-- 
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/pull/1796#issuecomment-425767078