Subject: Re: [quicwg/base-drafts] RTT Measurement for HelloRetryRequest (#879)

From: ianswett <[email-masked]>
Date: Wed, 01 Nov 2017 12:52:01 +0000 (UTC)

The inconsistencies aren't a contradiction, so I'm still confused about the problem this causes.

-- 
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/879#issuecomment-341097663

---

From: Patrick McManus <[email-masked]>
Date: Wed, 01 Nov 2017 08:47:46 -0700

(not specific to hrr) There is a general weirdness where you can send a client initial and then receive server cleartext but not an ack of the client initial leading to simultaneous (or even out of order) sending of more client initials and client cleartext. I think the HRR thing is similar. I don't react quite as strongly negatively to that as some other people, but either a mandatory ack or an implicit ack would solve it - while leaving it technically unconnected persists the problem.

-- 
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/879#issuecomment-341146729

---

From: ianswett <[email-masked]>
Date: Wed, 01 Nov 2017 09:09:45 -0700

Currently I believe we're in a state where we use implicit acks, but we also ack the handshake packets, so I think one could use either signal in their implementation.  However, it's illegal to bundle the ack of the handshake packet with the handshake packet itself.

-- 
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/879#issuecomment-341153636

---

From: Martin Thomson <[email-masked]>
Date: Wed, 01 Nov 2017 20:43:03 +0000 (UTC)

In Handshake packets (I'll use the new names...), we allow - and even encourage - the presence of ACK frames.  Normal rules apply there.  Given that there might be multiple Handshake packets, there might be an ACK in some but not others, but that's all fairly standard logic.  In other words, Handshake packets don't need this special consideration.

This also doesn't apply to an Initial packet that is sent in response to a Retry packet, because we expect the server not to maintain state.  Though it could, we expect that it doesn't, and so it won't be starting its RTT measurement until it receives Handshake packets from the client, on the next go 'round.

This question is specific to the Retry packet, which is singular and contains a way to precisely identify the Initial packet (it echoes the packet number).  You do really need to ensure that you treat receipt of a Retry packet as an implicit acknowledgment, if only so that you stop sending the same Initial packet.  The question then is whether it is - for the purposes of priming RTT measurements - better to use the implicit acknowledgment information always, or to use the same ACK-handling pathways that would be otherwise used.

-- 
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/879#issuecomment-341236094

---

From: Ryan Hamilton <[email-masked]>
Date: Sat, 04 Nov 2017 04:01:33 +0000 (UTC)

@martinthomson well said. I think you've clearly articulated the choices.

Not that we're voting, but your phrasing, "or to use the same ACK-handling pathways that would be otherwise used" is super compelling to me. If we always use the same ACK-handling pathway to deduce RTT, that makes implementations simpler. So that's definitely my preference.

But you are also totally right to observe that the implicit acknowledgement expresses the identical information and as such could clearly be made to work.

-- 
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/879#issuecomment-341869941