Subject: [quicwg/base-drafts] PATH_* frames are not ACK-eliciting (#2372)

From: Rui Paulo <[email-masked]>
Date: Sun, 27 Jan 2019 16:57:59 -0800

Recovery draft assumes only PADDING and ACK are not ACK-eliciting.  However, PATH_CHALLENGE is not ACK-eliciting since it's ACK'ed by PATH_RESPONSE. 

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

---

From: ianswett <[email-masked]>
Date: Sun, 27 Jan 2019 17:03:40 -0800

I'm not finding the text in transport that says they're not ack-eliciting, and I'd rather make them ack-eliciting unless there's an important reason they can't be.  I did find text that says acknowledgement is not a substitute for PATH_RESPONSE:
    "Receipt of an acknowledgment for a packet containing a
      PATH_CHALLENGE frame is not adequate validation, since the
      acknowledgment can be spoofed by a malicious peer."

-- 
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/2372#issuecomment-457971166

---

From: Rui Paulo <[email-masked]>
Date: Sun, 27 Jan 2019 17:42:47 -0800

https://quicwg.org/base-drafts/draft-ietf-quic-recovery.html#rfc.section.2

> Ack-eliciting Frames: All frames besides ACK or PADDING are considered ack-eliciting

I don't know how connection migration would work if PATH_CHALLENGE triggers PATH_RESPONSE+ACK since ACK is a non-probing frame (i.e., it triggers migration).

Or does this mean the PATH_CHALLENGE will be ACK'ed on the "main" path and the PATH_RESPONSE will be sent on the alternative path?

-- 
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/2372#issuecomment-457975185

---

From: ianswett <[email-masked]>
Date: Sun, 27 Jan 2019 17:52:18 -0800

I think you're supposed to send the ACK on the non-probing path, but I'm not the connection migration expert.

The main benefit of them not being ack-eliciting in my mind is it makes it clear that their loss should not cause a congestion control reaction.

-- 
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/2372#issuecomment-457976324

---

From: Rui Paulo <[email-masked]>
Date: Sun, 27 Jan 2019 18:02:33 -0800

I think it would greatly simplify things if they were made non ack-eliciting.  Like you said, if they are not ACK'ed then it doesn't change the congestion window.

-- 
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/2372#issuecomment-457977530

---

From: erickinnear <[email-masked]>
Date: Sun, 27 Jan 2019 18:09:24 -0800

I think the original intent was that they would be acked on the main path, but making them non ack-eliciting would also remove a (somewhat minor) linkability concern. 
Having them not influence congestion control seems like a strong reason to make them non ack-eliciting. 
Either way, seems like clarification would be helpful 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/issues/2372#issuecomment-457978374

---

From: Christian Huitema <[email-masked]>
Date: Sun, 27 Jan 2019 18:19:13 -0800

I implemented these frames as non ack eliciting. Trying to manage ACK for them would be weird.

-- 
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/2372#issuecomment-457979623

---

From: ianswett <[email-masked]>
Date: Sun, 27 Jan 2019 18:20:43 -0800

I'm happy to make these non ACK-eliciting now that I think about it more.

If anyone objects to this change, I'd like to hear why.

-- 
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/2372#issuecomment-457979816

---

From: Kazuho Oku <[email-masked]>
Date: Sun, 27 Jan 2019 19:24:21 -0800

Does making it non ACK-eliciting imply that we would no longer be allowed to bundle other types of frame in a path probing packet?

I think I am fine with that, but I would like to confirm what the impact is.

-- 
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/2372#issuecomment-457988114

---

From: erickinnear <[email-masked]>
Date: Sun, 27 Jan 2019 20:39:26 -0800

One potential thought: anything else that you bundle that would be ack-eliciting should also be considered an immediate migration and would cause the ack to come back on the new path, which means there's no issue. 
I think the new requirement would be: any frames considered probing packets that don't trigger migration should also be non ack-eliciting. 

-- 
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/2372#issuecomment-457996947

---

From: Kazuho Oku <[email-masked]>
Date: Sun, 27 Jan 2019 20:56:10 -0800

I think the issue is if we want probing packet to not be ACK-eliciting.

If the answer is yes, then we should consider what to do with other types of frames that are allowed to be included in a path probing packet: i.e., PATH_RESPONSE, NEW_CONNECTION_ID. I'd assume that we at least want NEW_CONNECTION_ID frame to be ACK-eliciting.

-- 
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/2372#issuecomment-457999005

---

From: Martin Thomson <[email-masked]>
Date: Tue, 29 Jan 2019 21:34:24 -0800

Tokyo conclusion: this is not easy, but what we have is tolerable.  If we obtain more data, then we will reopen the issue.

-- 
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/2372#issuecomment-458817952

---

From: Martin Thomson <[email-masked]>
Date: Wed, 30 Jan 2019 05:34:26 +0000 (UTC)

Closed #2372.

-- 
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/2372#event-2105576648

---

From: MikkelFJ <[email-masked]>
Date: Thu, 31 Jan 2019 08:43:46 -0800

If you consider future multi-path where you might want to ACK on specific paths for RTT reasons, it might simplify things to not mix in PATH_* in the equation.

If you consider RTT today, it might be misleading to ACK on a different path that could have a very different RTT measure.

-- 
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/2372#issuecomment-459415449