Subject: [quicwg/base-drafts] RTT Initial measurement (#2607)

From: Vidhi Goel <[email-masked]>
Date: Wed, 10 Apr 2019 15:44:56 -0700

On receiving the INITIAL packet, the server passes the CRYPTO data to TLS which then does a bunch of things like computing handshake key, generate INITIAL data etc and then passes it to QUIC. From measurements, it takes ~10ms before the server sends out the INITIAL packet and ACK for client's INITIAL packet.

Now, the first RTT measurement doesn't include ack delay. For a very low RTT connection (two machines connected back to back via ethernet), this causes the initial RTT ~ 10ms, which is too high for such a connection. Even after subsequent RTT samples of 0ms, would take a long time to normalize the high initial value.

Is there a reason why we don't subtract ack_delay from measured RTT for the INITIAL packet?

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

---

From: ianswett <[email-masked]>
Date: Thu, 11 Apr 2019 06:34:59 -0700

The reason to not subtract ack_delay on the first ACK is it could allow the peer to manipulate the SRTT, which may be particularly dangerous at the beginning of a connection.  As a mitigation, the current text in 4.1 of Recovery says: 
  "In order to quickly complete the handshake and avoid spurious
   retransmissions due to crypto retransmission timeouts, crypto packets
   SHOULD use a very short ack delay, such as the local timer
   granularity.  ACK frames MAY be sent immediately when the crypto
   stack indicates all data for that packet number space has been
   received."
https://tools.ietf.org/html/draft-ietf-quic-recovery-19#section-4.1

We could add some text indicating that sending an ACK immediately improves the first RTT sample if that seems helpful?

-- 
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/2607#issuecomment-482116436

---

From: ianswett <[email-masked]>
Date: Thu, 11 Apr 2019 13:36:24 +0000 (UTC)

PR #2592 is a substantial rewrite of the RTT estimation section, so it may be worth reading that to see if it provides the rationale you were looking for.

-- 
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/2607#issuecomment-482116904

---

From: Jana Iyengar <[email-masked]>
Date: Thu, 11 Apr 2019 19:46:14 -0700

This is an interesting point. In addition to having an inflated RTT,
there's also the risk of the crypto timer firing for long RTTs.

In quicly, we don't delay acks during the handshake to avoid these issues.
I wonder if this is worth mentioning in the draft.

On Thu, Apr 11, 2019, 6:36 AM ianswett <[email-masked]> wrote:

> PR #2592 <https://github.com/quicwg/base-drafts/pull/2592> is a
> substantial rewrite of the RTT estimation section, so it may be worth
> reading that to see if it provides the rationale you were looking for.
>
> —
> Reply to this email directly, view it on GitHub
> <https://github.com/quicwg/base-drafts/issues/2607#issuecomment-482116904>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/AKjg1FXR46ZwF6fpEeRZ2ovL5iPor_Vgks5vfzpWgaJpZM4coZTW>
> .
>

-- 
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/2607#issuecomment-482415803

---

From: Marten Seemann <[email-masked]>
Date: Fri, 12 Apr 2019 01:43:29 -0700

@janaiyengar, we already have [text about this](https://quicwg.org/base-drafts/draft-ietf-quic-recovery.html#crypto-handshake-data):
> In order to quickly complete the handshake and avoid spurious retransmissions due to crypto retransmission timeouts, crypto packets SHOULD use a very short ack delay, such as the local timer granularity. ACK frames MAY be sent immediately when the crypto stack indicates all data for that packet number space has been received.

-- 
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/2607#issuecomment-482491524

---

From: Martin Thomson <[email-masked]>
Date: Fri, 12 Apr 2019 05:59:22 -0700

That "MAY" is odd.  You can always ACK immediately.  Whether or not you "SHOULD" varies, but in this case maybe we SHOULD RECOMMEND an immediate ACK rather than having it be OPTIONAL.

-- 
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/2607#issuecomment-482565005

---

From: ianswett <[email-masked]>
Date: Fri, 12 Apr 2019 14:07:21 +0000 (UTC)

I believe the MAY is only possible if the crypto stack provides a clear signal that it's received all crypto data in Initial or Handshake packets?  I wasn't sure how likely that was to be available, which is why it's a MAY, but I'm also happy to make it a SHOULD.

The text used to say you should always ACK crypto packets immediately, but a client might want to wait a short period of time and ACK the servers Initial in a coalesced packet with the client's Handshake ACK/CFIN, so it was adjusted to " a very short ack delay, such as the local timer granularity".

-- 
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/2607#issuecomment-482587748

---

From: Kazuho Oku <[email-masked]>
Date: Fri, 12 Apr 2019 09:17:53 -0700

Agrees to what @ianswett says.

"SHOULD if the crypto stack provides such signal" is what I'd favor to see in the text, I think the current text implies 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/issues/2607#issuecomment-482634987

---

From: Jana Iyengar <[email-masked]>
Date: Fri, 12 Apr 2019 17:41:35 -0700

@marten-seemann :  indeed, thanks for pointing me to the text. I'm in agreement as well on turning the MAY into a SHOULD. I'll send 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/2607#issuecomment-482760877

---

From: Jana Iyengar <[email-masked]>
Date: Fri, 12 Apr 2019 18:47:13 -0700

Closed #2607 via #2614.

-- 
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/2607#event-2273870254

---

From: Vidhi Goel <[email-masked]>
Date: Fri, 12 Apr 2019 21:22:01 -0700

Sending an ACK immediately for client's INITIAL might be helpful in estimating RTT correctly but it has the disadvantage of not being able to coalesce the ACK with server's INITIAL CRYPTO. Some implementations might even coalesce the Handshake packet.

-- 
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/2607#issuecomment-482774829

---

From: Jana Iyengar <[email-masked]>
Date: Mon, 15 Apr 2019 19:40:05 -0700

@goelvidhi : that is already covered by the current text.

-- 
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/2607#issuecomment-483488966