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

From: Martin Thomson <[email-masked]>
Date: Mon, 16 Oct 2017 21:19:52 -0700

In #817, @marten-seemann asks why the server can't send an ACK with its HelloRetryRequest.

I had assumed that this ACK would be pointless.  Obviously, the server can only acknowledge a single packet (the Initial packet), and this is implicitly acknowledged.  The only information that the packet might now contain is the ACK Delay field now that we removed the timestamps from the default ACK format.  That assumes that the server is delaying its response in any way or that its processing is somehow significant enough to be worth measuring.  I don't think that the server has any reason to delay the generation of a HelloRetryRequest, and the entire design depends on the processing time required to generate it is minimal.

Did I miss something?

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

---

From: Ryan Hamilton <[email-masked]>
Date: Tue, 17 Oct 2017 06:14:15 +0000 (UTC)

It's possible for a client to underestimate the RTT to the server, send a ClientHello and then retransmit it. The server could receive the first ClientHello and send a HelloRetryRequest in response. But at this point the client may think that the HelloRetryRequest is in response to the second retransmitted ClientHello. So by sending an ACK, the client can learn if ClientHello 1 or 2 was the packet which elicited the HelloRetryRequest.

-- 
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-337128635

---

From: Martin Thomson <[email-masked]>
Date: Tue, 17 Oct 2017 06:21:35 +0000 (UTC)

That's not a problem: the different packets containing ClientHello will include a different packet number, which is echoed in the packet carrying the HelloRetryRequest.

-- 
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-337129901

---

From: Marten Seemann <[email-masked]>
Date: Tue, 17 Oct 2017 07:06:25 +0000 (UTC)

There are two issues here:

1. Even if possible in theory, do we really want to introduce a separate way for RTT measurements independent of ACKs, which only applies for the first packet?
2. Do we really want to introduce extra logic to make sure that the HRR packet doesn’t include an ACK, and to verify that on the receiver side?

I think the answer to both questions is no. Including an ACK is cheap (just a few bytes) and all the ACKing logic is already in place. I think we should revert #817, or maybe even go a step further and make including an ACK with the HRR recommended.

-- 
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-337138131

---

From: ianswett <[email-masked]>
Date: Tue, 17 Oct 2017 06:22:47 -0700

I think Marten outlines the issue well.

In GQUIC, we experimented with writing some handshake specific code for a while, but it never worked correctly, so we decided it was a lot easier to just use the existing ACK frame.

Whichever way we go, we should clarify how one is expected to obtain an RTT sample to feed into the next connection attempt.

-- 
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-337229467

---

From: Patrick McManus <[email-masked]>
Date: Tue, 17 Oct 2017 14:22:49 +0000 (UTC)

no matter what we do there is going to be some cognitive dissonance.
Elsewhere we say "The client client .. discards all transport state" upon
receipt. So its not really a traditional ack in that sense either (i.e. if
the server did not send the ACK you would not keep transmitting the info of
the old CI which has been reset).

In short - I don't think it matters if its implicit or explicit, this will
be kinda ugly either way. I like implicit myself but whatever :)

-- 
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-337247690

---

From: janaiyengar <[email-masked]>
Date: Tue, 17 Oct 2017 17:19:56 +0000 (UTC)

@mcmanus: The goal was to allow the sender to retain some state, esp. RTT,
across an HRR, but discard other state. This is very useful for the
handshake timeout, since there's really no other value to seed the timeout
with. Section 5.4.2 says what you wrote, but also says "The client MAY also
retain any observed RTT or congestion state that it has accumulated for the
flow, but other transport state MUST be discarded."

I agree with Marten -- it's unnecessary to create separate RTT logic for
this. What do we get for getting rid of ACKs here?

On Tue, Oct 17, 2017 at 7:22 AM, Patrick McManus <[email-masked]>
wrote:

> —
> Reply to this email directly, view it on GitHub
> <https://github.com/quicwg/base-drafts/issues/879#issuecomment-337247690>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/AKjg1IsZuRs9XWLzjtnOxcdJZnao_k7Eks5stLg4gaJpZM4P7j43>
> .
>

-- 
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-337291830

---

From: ekr <[email-masked]>
Date: Tue, 17 Oct 2017 10:47:52 -0700

> this. What do we get for getting rid of ACKs here?

You avoid creating situations where the ACK state of this record is
inconsistent.
As McManus says, you are implicitly ACKing the CI by sending this message.

> On Tue, Oct 17, 2017 at 7:22 AM, Patrick McManus <[email-masked]
> >
> wrote:
>
> > <https://github.com/quicwg/base-drafts/issues/879#issuecomment-337247690
> >,
> > or mute the thread
> > <https://github.com/notifications/unsubscribe-auth/
> AKjg1IsZuRs9XWLzjtnOxcdJZnao_k7Eks5stLg4gaJpZM4P7j43>
> > .
>
> >
>
> —
> <https://github.com/quicwg/base-drafts/issues/879#issuecomment-337291830>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/ABD1oR4hIWqQW6gU4zHd4iJ4EtjjlZojks5stOG4gaJpZM4P7j43>
> .
>

-- 
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-337306288

---

From: janaiyengar <[email-masked]>
Date: Tue, 31 Oct 2017 16:14:07 -0700

I'd still prefer having an ACK frame in there simply because that part of the code doesn't have to be special cased for an HRR being an ACK. PR #882 seems like a good compromise; it doesn't require an ACK be sent, so I'd like to see that be merged.

-- 
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-340934458

---

From: ianswett <[email-masked]>
Date: Tue, 31 Oct 2017 23:35:27 +0000 (UTC)

I would like to never rely on the word 'implicit' in the QUIC spec.  One can use implicit information, but I don't think it should be critical to correctness.

I'm not hearing a clear argument about why this is harmful.  One certainly could create an ack frame that doesn't ack the correct packets, but that seems like a general bug, not one specific to this case.

-- 
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-340937923

---

From: ekr <[email-masked]>
Date: Wed, 01 Nov 2017 02:14:29 +0000 (UTC)

On Tue, Oct 31, 2017 at 4:35 PM, ianswett <[email-masked]> wrote:

> I would like to never rely on the word 'implicit' in the QUIC spec. One
> can use implicit information, but I don't think it should be critical to
> correctness.
>
> I'm not hearing a clear argument about why this is harmful.
>
It creates the possibility of inconsistencies between facts. Namely, it's
obvious the packet was received and you shouldn't be retransmitting, but
yet if there's no ACK.

> One certainly could create an ack frame that doesn't ack the correct
> packets, but that seems like a general bug, not one specific to this case.
>
I guess I see it differently. A topic for Singapore, I guess.

-- 
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-340958653