Subject: Re: [quicwg/base-drafts] Word-smithed version of Ted's resolution to #3842 from the mailing list (#3945)

From: ianswett <[email-masked]>
Date: Tue, 04 Aug 2020 15:56:30 -0700

@ianswett approved this pull request.

-- 
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/3945#pullrequestreview-461230911

---

From: Nick Banks <[email-masked]>
Date: Tue, 04 Aug 2020 15:58:11 -0700

@nibanks approved this pull request.

-- 
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/3945#pullrequestreview-461231580

---

From: Mike Bishop <[email-masked]>
Date: Thu, 13 Aug 2020 08:58:50 -0700

@MikeBishop approved this pull request.

-- 
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/3945#pullrequestreview-466900324

---

From: Lars Eggert <[email-masked]>
Date: Thu, 13 Aug 2020 09:04:35 -0700

@larseggert commented on this pull request.

>  immediately reset the congestion controller and round-trip time estimator for
 the new path to initial values (see Appendices A.3 and B.3 in {{QUIC-RECOVERY}})
-unless it has knowledge that a previous send rate or round-trip time estimate is
-valid for the new path.  For instance, an endpoint might infer that a change in
-only the client's port number is indicative of a NAT rebinding, meaning that the
-new path is likely to have similar bandwidth and round-trip time. However, this
-determination will be imperfect.  If the determination is incorrect, the
-congestion controller and the RTT estimator are expected to adapt to the new
-path.  Generally, implementations are advised to be cautious when using previous
-values on a new path.
+unless the only change is the other endpoint's port number.  Because

On the mailing list, I asked whether I should add "and the connection ID did not change" to the end of this sentence. Opinions?

-- 
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/3945#pullrequestreview-466905190

---

From: Mike Bishop <[email-masked]>
Date: Thu, 13 Aug 2020 09:07:36 -0700

@MikeBishop commented on this pull request.

I think not.  Implementations that know they're likely to have a NAT rebinding (i.e. after quiescence) are advised to change the CID as well.  That doesn't make it less a NAT rebinding.

-- 
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/3945#discussion_r470063211

---

From: Lars Eggert <[email-masked]>
Date: Thu, 13 Aug 2020 09:09:38 -0700

The point is that _if_ the CID changed, it was an active migration attempt, which indicates that the peer at least attempted to switch paths.

-- 
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/3945#discussion_r470064350

---

From: Jana Iyengar <[email-masked]>
Date: Thu, 13 Aug 2020 12:48:30 -0700

@janaiyengar commented on this pull request.

```suggestion
unless the only change in the peer's address is its port number.  Because
```

+port-only changes are commonly the result of NAT rebinding or other middlebox
+activity, an endpoint MAY instead retain its congestion control state and

```suggestion
activity, the endpoint MAY instead retain its congestion control state and
```

Yeah, I agree that it's consistent with the idea that the peer likely changed its attachment point. I don't think this makes a difference in practice, but it seems consistent with our principles here.

It does make it a bit more work to check, but it's not that hard.

-- 
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/3945#pullrequestreview-467075399

---

From: Mike Bishop <[email-masked]>
Date: Thu, 13 Aug 2020 12:50:49 -0700

Correctly predicting a NAT rebind isn't an "attempt" to switch paths.  It's using the same path, but making a guess about what might have happened.

If you're not going to reset the congestion controller when the port changes without the peer realizing it, and you're not going to reset the congestion controller if the peer guesses they're about to get rebound but doesn't, then I don't think it makes sense to reset it if they guess and are right.

-- 
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/3945#discussion_r470207946

---

From: Jana Iyengar <[email-masked]>
Date: Thu, 13 Aug 2020 13:00:20 -0700

That's fair, but why would a peer change the CID for a NAT rebinding?

-- 
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/3945#discussion_r470213122

---

From: Mike Bishop <[email-masked]>
Date: Thu, 13 Aug 2020 13:49:46 -0700

We encourage changing the CID and port to "force" a NAT rebinding if you've been idle (Section 9.5) in order to reduce linkability.  In the same breath, we note that this might reset congestion controller state, so be careful about changing port too often.  A conservative implementation of that guidance might change CID but not port, letting NAT rebindings happen if they happen.

-- 
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/3945#discussion_r470239839

---

From: Lars Eggert <[email-masked]>
Date: Fri, 14 Aug 2020 00:01:47 -0700

This sounds like the address _includes_ the port number, which in my mental model it doesn't?

-- 
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/3945#discussion_r470446059

---

From: Lars Eggert <[email-masked]>
Date: Fri, 14 Aug 2020 00:02:21 -0700

@larseggert pushed 1 commit.

e824ab9da788c5ccd776cf14e6c773e94ee9a461  Update draft-ietf-quic-transport.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3945/files/b4cce75456f669de76183ce12ce515b4c9b210dc..e824ab9da788c5ccd776cf14e6c773e94ee9a461

---

From: Lars Eggert <[email-masked]>
Date: Fri, 14 Aug 2020 00:06:34 -0700

I don't see how the text in Section 9.5 conflicts with the proposed change?

-- 
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/3945#discussion_r470447859

---

From: mirjak <[email-masked]>
Date: Fri, 14 Aug 2020 05:40:42 -0700

@mirjak commented on this pull request.

-only the client's port number is indicative of a NAT rebinding, meaning that the
-new path is likely to have similar bandwidth and round-trip time. However, this
-determination will be imperfect.  If the determination is incorrect, the
-congestion controller and the RTT estimator are expected to adapt to the new
-path.  Generally, implementations are advised to be cautious when using previous
-values on a new path.
+unless the only change is the other endpoint's port number.  Because
+port-only changes are commonly the result of NAT rebinding or other middlebox
+activity, the endpoint MAY instead retain its congestion control state and
+round-trip estimate in those cases instead of reverting to initial values.
+In cases where congestion control state
+retained from an old path is used on a new path with substantially different
+characteristics, a sender may transmit too aggressively until the congestion
+controller and the RTT estimator have adapted. Generally, implementations are
+advised to be cautious when using previous values on a new path.

This last sentence sounds like it generally good advise to reuse (just be cautious about it).  I don't think that is a general good advise for all kind of value. For some it might be (with cautious) but in any case I would need more words that this in order to give any recommendation.

-- 
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/3945#pullrequestreview-467541864

---

From: mirjak <[email-masked]>
Date: Fri, 14 Aug 2020 05:41:40 -0700

Sorry I know this sentence was there in the old text but given we ware looking at this we should either remove this part of give more advise/pointers.

-- 
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/3945#discussion_r470599403

---

From: Lars Eggert <[email-masked]>
Date: Fri, 14 Aug 2020 05:47:07 -0700

I read that sentence completely differently, but maybe "implementations should be careful when using" is clearer?

-- 
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/3945#discussion_r470601972

---

From: Mike Bishop <[email-masked]>
Date: Fri, 14 Aug 2020 11:39:13 -0700

[Section 1.2](https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#name-terms-and-definitions):
> Address:
> When used without qualification, the tuple of IP version, IP address, and UDP port number that represents one end of a network 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/pull/3945#discussion_r470801301

---

From: Lars Eggert <[email-masked]>
Date: Fri, 14 Aug 2020 11:57:26 -0700

Right, but @janaiyengar's change makes it sound like the _port_ is _in_ the address. Maybe "unless the only change in the peer's endpoint is its port number"?

-- 
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/3945#discussion_r470812811

---

From: Mike Bishop <[email-masked]>
Date: Fri, 14 Aug 2020 12:54:11 -0700

I don't think "endpoint" would be wrong, but "address" per the definition in this document does include the port number.

-- 
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/3945#discussion_r470836778

---

From: Mike Bishop <[email-masked]>
Date: Fri, 14 Aug 2020 13:01:46 -0700

Whether an endpoint passively experiences or deliberately forces a NAT rebind is indistinguishable at the server side.  Changing CID tells you nothing more than that they wanted to reduce their linkability if they got rebound.  A change in CID doesn't imply a path change; a change in endpoint address is the only reliable guide on that.

We're saying that you SHOULD reset unless there's a change that's broader than the port, because a port-only change is very likely to be the same path.  A CID change is even less likely to indicate a path change.  Therefore, it should not be a cause for resetting the congestion controller.

-- 
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/3945#discussion_r470839962

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 18 Aug 2020 13:58:15 -0700

@MikeBishop: I see your point. The concern @larseggert was trying to address was that in some carrier-grade NATs, it is possible that what appears as a port change might actually be a path change on the private side of the CGNAT, but your point is that CID change cannot be assumed to be a good proxy for path change. At a minimum, we don't have experience with this yet, so we can't assume it.

I don't have a strong opinion one way or the other here. In practice, I completely expect people to treat port changes as same path. Given @MikeBishop's point about CID changes also not reflecting a path change, I would suggest leaving the PR as it 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/pull/3945#discussion_r472488858

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 18 Aug 2020 14:02:00 -0700

I was proposing two changes:
- we've used endpoint and peer as the two sides. Because you've used "endpoint" for this end, I'm suggesting using "peer" for the other end.
- we've used address to mean IP and port, so saying "the change in the address" was simply to clarify that the "only" is scoped to the address (and not to other things, like CID). Your current text says "the only change is" without saying the only change to what.

-- 
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/3945#discussion_r472490843

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 18 Aug 2020 14:04:03 -0700

This is not a recommendation. The advise there seems appropriate to me; is there specific other advise that is needed?

-- 
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/3945#discussion_r472491764

---

From: Lars Eggert <[email-masked]>
Date: Tue, 18 Aug 2020 23:36:34 -0700

7a2289a2400b22662a4a72227395dd955530fa57  Update draft-ietf-quic-transport.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3945/files/e824ab9da788c5ccd776cf14e6c773e94ee9a461..7a2289a2400b22662a4a72227395dd955530fa57

---

From: Jana Iyengar <[email-masked]>
Date: Wed, 19 Aug 2020 00:48:37 -0700

@janaiyengar approved this pull request.

-- 
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/3945#pullrequestreview-470206536

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 20 Aug 2020 20:56:54 -0700

@kazuho approved this pull request.

-- 
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/3945#pullrequestreview-472128853

---

From: Christian Huitema <[email-masked]>
Date: Fri, 21 Aug 2020 08:50:12 -0700

@huitema approved this pull request.

-- 
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/3945#pullrequestreview-472602802

---

From: ianswett <[email-masked]>
Date: Sat, 29 Aug 2020 09:42:06 -0700

-- 
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/3945#pullrequestreview-478140107

---

From: Marten Seemann <[email-masked]>
Date: Sun, 30 Aug 2020 03:58:50 -0700

@marten-seemann approved this pull request.

+unless the only change in the peer's address is its port number.  Because

```suggestion
characteristics, a sender would transmit too aggressively until the congestion
```

-- 
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/3945#pullrequestreview-478192677

---

From: mirjak <[email-masked]>
Date: Mon, 31 Aug 2020 02:18:38 -0700

> @@ -2432,17 +2432,18 @@ The capacity available on the new path might not be the same as the old path.
 Packets sent on the old path MUST NOT contribute to congestion control or RTT
 estimation for the new path.
 
-On confirming a peer's ownership of its new address, an endpoint MUST
+On confirming a peer's ownership of its new address, an endpoint SHOULD

Why was this changed to a MUST? I thought if there is "unless" condition, MUST is the right choice.

-- 
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/3945#pullrequestreview-478450158

---

From: Lars Eggert <[email-masked]>
Date: Mon, 31 Aug 2020 03:52:14 -0700

Not necessarily - if the new path has more capacity than the old one, the sender would not send to aggressively.

-- 
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/3945#discussion_r480047533

---

From: Lars Eggert <[email-masked]>
Date: Mon, 31 Aug 2020 03:53:32 -0700

It was changed to SHOULD because we added the "unless" clause. This is exactly what a SHOULD is 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/pull/3945#discussion_r480048014

---

From: mirjak <[email-masked]>
Date: Mon, 31 Aug 2020 05:02:56 -0700

This is a thing I'm never sure about but I would use MUST with an explicit exception. While SHOULD would mean there might be more exceptions...

-- 
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/3945#discussion_r480083617

---

From: Lars Eggert <[email-masked]>
Date: Mon, 31 Aug 2020 05:48:13 -0700

I was under the impression that a MUST with an exception was a SHOULD, per 2119. I have no problems if that understanding is wrong, although a MUST...unless just feels odd. What do others think?

-- 
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/3945#discussion_r480106563

---

From: Lars Eggert <[email-masked]>
Date: Mon, 31 Aug 2020 07:31:56 -0700

@MikeBishop is there something left to resolve 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/3945#discussion_r480170434

---

From: Jana Iyengar <[email-masked]>
Date: Mon, 31 Aug 2020 12:28:31 -0700

We've used "MUST ... unless" in the document to carve out specific exceptions. RFC 2119 says that violating a SHOULD is allowed if the implementer knows what they're doing. "MUST ... unless" is more prescriptive -- it says that the implementer can ignore the MUST only under the exceptional condition.

In this instance, I agree with @mirjak that "MUST ... unless" is the intent.

-- 
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/3945#discussion_r480348791