Subject: Consensus call for Late-Stage documents, pre-IETF 108 edition

From: Lucas Pardue <[email-masked]>
Date: Wed, 22 Jul 2020 03:00:09 +0100

Folks,

The following issues have proposals for resolution, and discussion so far
seems
to support consensus to accept them. Therefore, we are starting a 1-week
consensus call. If you object to a proposal, please do so on the issue or
in response to this message (changing the Subject appropriately!). Absent
any
pushback, we'll direct the editors to incorporate proposals once the call
concludes.

See <https://github.com/quicwg/base-drafts/projects/5> for the current
state of
issues in the Late Stage process, itself defined at
<https://github.com/quicwg/base-drafts/blob/master/CONTRIBUTING.md>.

* #3880: How long is a validated address good for?
  The proposal is to lose with no action.

* #3875: Persistent congestion threshold is unreliable during the early
stages of a connection
  The proposal is <https://github.com/quicwg/base-drafts/pull/3889>

* #3860: incorrect error code used for invalid RETIRE_CONNECTION_ID frames
  The proposal is <https://github.com/quicwg/base-drafts/pull/3861>

* #3845: What does "MUST reduce" mean?
  The proposal is https://github.com/quicwg/base-drafts/pull/3864

* #3842: Do I need to reset congestion info when the port changes?
  The proposal is to close with no action.

* #3834: Remove amplification throttle if the server receives Initial that
echoes its high entropy SCID.
  The proposal is <https://github.com/quicwg/base-drafts/pull/3924>

* #3808: Versions are for endpoints
  The proposal is <https://github.com/quicwg/base-drafts/pull/3785>

* #3800: Coalescing different CIDs for same connection
  The proposal is <https://github.com/quicwg/base-drafts/pull/3930>

Cheers,
Lars, Lucas and Mark
QUIC WG Chairs

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 21 Jul 2020 20:11:52 -0700

>   The proposal is to close with no action.

Assuming I understand this proposal, I object to this resolution. I do not
believe that the current text is appropriate.

As I said, I don't have a strong opinion about the outcome, but we
shouldn't just hint to people that they should ignore the port.

-Ekr

---

From: Lars Eggert <[email-masked]>
Date: Wed, 22 Jul 2020 10:36:17 +0300

Hi,

On 2020-7-22, at 6:11, Eric Rescorla <[email-masked]> wrote:
> As I said, I don't have a strong opinion about the outcome, but we shouldn't just hint to people that they should ignore the port.

existing protocols basically just broke when a port or IP address changed (e.g., a NAT rebinding happened). So how to respond to this is something that we don't have existing IETF practice for AFAIK.

The conservative approach would be to mandate a CC reset on any change to the four-tuple, since it indicates a possible path change.

For clients in consumer access networks behind CPE NATs, that conservative approach is probably too conservative, since the CC-relevant properties of the path are unlikely to have changed if just the source port changed.

On the other hand, with client side CGNs and server-side BALBs (big-ass load balancers...) a port change now maybe is more indicative of a path change. But it's not clear that this path change is more likely to affect the CC-relevant path characteristics.

One final thing I'll point out is that all IETF transports have been happily ignoring at least one path change indication since forever - there is no mandated reaction to any change in the received IP TTL, and I'm also unaware of any implementation reacting to IP TTL changes (which would indicate a change in path length, something that probably would lead to CC-relevant changes in path characteristics.)

That, together with the observation that CC will react to a path change anyway after an RTT due to loss/marks, leads me to believe we're probably OK to not reset CC on a port change. It might mean that we're sending for about an RTT at a rate that is too high in some rare (?) cases, but in the vast majority of cases, we'd avoid needless performance degradations.

YMMV.

Lars

---

From: Ted Hardie <[email-masked]>
Date: Wed, 22 Jul 2020 07:47:45 -0700

If ekr's objections is that this is a hint, rather than more explicit, we
can incorporate Lars' point by a minor adjustment of the text:

OLD:

On confirming a peer's ownership of its new address, an endpoint MUST
immediately reset the congestion controller and round-trip time estimator
for
the new path to initial values (see Sections 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.

NEW:

On confirming a peer's ownership of its new address, an endpoint SHOULD
reset the congestion controller and round-trip time estimator for the new
path to
initial values (see Sections A.3 and B.3 in {{QUIC-RECOVERY}}) unless the
change is only to the client's port number.  Because port-only changes
are commonly the result of NAT rebinding or other middlebox activity,
the client MAY retain its estimation of the path bandwidth and round-trip
time
in those cases.  A conservative implementation may also revert to initial
values
in this case.

That shifts it from hint territory to explicit resolution.

regards,

Ted

On Wed, Jul 22, 2020 at 12:36 AM Lars Eggert <[email-masked]> wrote:

> existing protocols basically just broke when a port or IP address changed
> (e.g., a NAT rebinding happened). So how to respond to this is something
> that we don't have existing IETF practice for AFAIK.
>
> The conservative approach would be to mandate a CC reset on any change to
> the four-tuple, since it indicates a possible path change.
>
> For clients in consumer access networks behind CPE NATs, that conservative
> approach is probably too conservative, since the CC-relevant properties of
> the path are unlikely to have changed if just the source port changed.
>
> On the other hand, with client side CGNs and server-side BALBs (big-ass
> load balancers...) a port change now maybe is more indicative of a path
> change. But it's not clear that this path change is more likely to affect
> the CC-relevant path characteristics.
>
> One final thing I'll point out is that all IETF transports have been
> happily ignoring at least one path change indication since forever - there
> is no mandated reaction to any change in the received IP TTL, and I'm also
> unaware of any implementation reacting to IP TTL changes (which would
> indicate a change in path length, something that probably would lead to
> CC-relevant changes in path characteristics.)
>
> That, together with the observation that CC will react to a path change
> anyway after an RTT due to loss/marks, leads me to believe we're probably
> OK to not reset CC on a port change. It might mean that we're sending for
> about an RTT at a rate that is too high in some rare (?) cases, but in the
> vast majority of cases, we'd avoid needless performance degradations.
>
> YMMV.
>
> Lars
>

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 22 Jul 2020 09:44:58 -0700

Ted's proposal would be acceptable to me.

-Ekr

On Wed, Jul 22, 2020 at 7:48 AM Ted Hardie <[email-masked]> wrote:

> valid for the new path. For instance, an endpoint might infer that a
> change in
>> For clients in consumer access networks behind CPE NATs, that
>> conservative approach is probably too conservative, since the CC-relevant
>> properties of the path are unlikely to have changed if just the source port
>> changed.
>>

---

From: Christian Huitema <[email-masked]>
Date: Wed, 22 Jul 2020 12:43:21 -0700

Sounds good to me too.

-- Christian Huitema

On 7/22/2020 9:44 AM, Eric Rescorla wrote:
> On Wed, Jul 22, 2020 at 7:48 AM Ted Hardie <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     If ekr's objections is that this is a hint, rather than more
>     explicit, we can incorporate Lars' point by a minor adjustment of
>     the text:
>
>     OLD:
>
>     immediately reset the congestion controller and round-trip time
>     estimator for
>     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
>     reset the congestion controller and round-trip time estimator for
>     the new path to
>     the client MAY retain its estimation of the path bandwidth and
>     round-trip time
>     in those cases..  A conservative implementation may also revert to
>     initial values
>     in this case.
>
>     On Wed, Jul 22, 2020 at 12:36 AM Lars Eggert <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>         Hi,
>
>         On 2020-7-22, at 6:11, Eric Rescorla <[email-masked]
>         <mailto:[email-masked]>> wrote:
>         > As I said, I don't have a strong opinion about the outcome,
>         but we shouldn't just hint to people that they should ignore
>         the port.
>
>         existing protocols basically just broke when a port or IP
>         address changed (e.g., a NAT rebinding happened). So how to
>         respond to this is something that we don't have existing IETF
>         practice for AFAIK.
>
>         The conservative approach would be to mandate a CC reset on
>         any change to the four-tuple, since it indicates a possible
>         path change.
>
>         conservative approach is probably too conservative, since the
>         CC-relevant properties of the path are unlikely to have
>         changed if just the source port changed.
>
>         On the other hand, with client side CGNs and server-side BALBs
>         (big-ass load balancers...) a port change now maybe is more
>         indicative of a path change.. But it's not clear that this
>         path change is more likely to affect the CC-relevant path
>         characteristics.
>
>         One final thing I'll point out is that all IETF transports
>         have been happily ignoring at least one path change indication
>         since forever - there is no mandated reaction to any change in
>         the received IP TTL, and I'm also unaware of any
>         implementation reacting to IP TTL changes (which would
>         indicate a change in path length, something that probably
>         would lead to CC-relevant changes in path characteristics.)
>
>         That, together with the observation that CC will react to a
>         path change anyway after an RTT due to loss/marks, leads me to
>         believe we're probably OK to not reset CC on a port change. It
>         might mean that we're sending for about an RTT at a rate that
>         is too high in some rare (?) cases, but in the vast majority
>         of cases, we'd avoid needless performance degradations..
>
>         YMMV.
>
>         Lars
>

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 23 Jul 2020 10:36:23 +1000

Is the intent to avoid talking about what knowledge an endpoint might use to decide to transfer state?

On Thu, Jul 23, 2020, at 05:43, Christian Huitema wrote:
> >> If ekr's objections is that this is a hint, rather than more explicit, we can incorporate Lars' point by a minor adjustment of the text:
> >> 
> >> OLD: 
> >> 
> >> immediately reset the congestion controller and round-trip time estimator for
> >> the new path to initial values (see Sections 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
> >> reset the congestion controller and round-trip time estimator for the new path to 
> >> the client MAY retain its estimation of the path bandwidth and round-trip time
> >> in those cases..  A conservative implementation may also revert to initial values
> >> in this case.
> >> 
> >>> On the other hand, with client side CGNs and server-side BALBs (big-ass load balancers...) a port change now maybe is more indicative of a path change.. But it's not clear that this path change is more likely to affect the CC-relevant path characteristics.
> >>> 
> >>> That, together with the observation that CC will react to a path change anyway after an RTT due to loss/marks, leads me to believe we're probably OK to not reset CC on a port change. It might mean that we're sending for about an RTT at a rate that is too high in some rare (?) cases, but in the vast majority of cases, we'd avoid needless performance degradations..
> >>> 
> >>> YMMV.
> >>> 
> >>> Lars

---

From: Lars Eggert <[email-masked]>
Date: Thu, 23 Jul 2020 08:43:45 +0300

> Ted's proposal would be acceptable to me.

I've done a small PR based on Ted's proposed text in https://github.com/quicwg/base-drafts/pull/3945

Lars

---

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 23 Jul 2020 08:09:26 +0100

I think this change is wrong from a congestion control perspective. To 
me this appears a significant congestion control change from  the 
current practice of IETF protocols, which make a conservative reaction.

See below:

>>>>> One final thing I'll point out is that all IETF transports have been happily ignoring at least one path change indication since forever - there is no mandated reaction to any change in the rece…
I agree with Lars that devices have traditionally ignored TTL/Hop Count 
changes, based on the assumption that small route changes don't have 
large impact - however, an important difference is that the proposed 
change modifies the input information that can be used to deterime the 
IP forwarding path in relation to traffic classification/queuing (e.g. 
SFQ) and set of devices on path.
>>>>> That, together with the observation that CC will react to a path change anyway after an RTT due to loss/marks, leads me to believe we're probably OK to not reset CC on a port change. It might m…

I thought the point that NAPT was common point had been discussed in 
QUIC before, and was noted that there are devices on path that change 
the forwrading path and hence congestion conditions based on the flow's 
port value. ECMP is a not that uncommon example, other load ballancing 
can also change the path. I understood that QUIC was seeking to avoid 
defining new congestion control approaches, and this proposal would seem 
to move in that direction.

Once a new path has been confirmed and the RTT discovered, I would 
expect there are actually opportunities to utilise the previous path 
information to quickly more to restore the ratye, but I think that 
simply ignoring such a path change can make a seriously wrong congetsion 
assumption - especially when accompanied by a significant RTT change.

Gorry

---

From: Lars Eggert <[email-masked]>
Date: Thu, 23 Jul 2020 10:22:31 +0300

Hi,

On 2020-7-23, at 10:09, Gorry Fairhurst <[email-masked]> wrote:
> I thought the point that NAPT was common point had been discussed in QUIC before, and was noted that there are devices on path that change the forwrading path and hence congestion conditions based on the flow's port value. ECMP is a not that uncommon example, other load ballancing can also change the path.

but with ECMP, SFQ and similar schemes, the intent it spread the load equally over a set of candidate paths. So, assuming some level of utilization, all those candidate paths should have more-or-less similar path characteristics?

I agree that in general, a path change should cause a CC state reset, but in this specific case, I think we can make some assumptions (like the above) that may make it OK to not do that.

Lars

---

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 23 Jul 2020 08:34:40 +0100

See below,

On 23/07/2020 08:22, Lars Eggert wrote:
> but with ECMP, SFQ and similar schemes, the intent it spread the load equally over a set of candidate paths.
>   So, assuming some level of utilization, all those candidate paths should have more-or-less similar path characteristics?

If you consider all paths equal, then sure, but how can you make that 
assumption?

If you assume this can only happen when the chosen paths have similar 
condictions, then I'd have to agree - but how can it be assumed that 
paths have equivalent unused capacity?

These methods often hash based on port, IP, and maybe other fields to 
select a queue - There are a finite set of queues, a rehash results in 
the traffic moving queue ... to chooses a different path or queue within 
the device. This mapping is statistical, this matters more if the 
multiplexing is low and a port change results in unbalance across 
quques/paths.

> I agree that in general, a path change should cause a CC state reset, but in this specific case, I think we can make some assumptions (like the above) that may make it OK to not do that.

I still think this is a new CC decision, and the charter explicitly says 
that this version of QUIC will not make new congestion controllers.

Gorry

---

From: Lars Eggert <[email-masked]>
Date: Thu, 23 Jul 2020 10:42:26 +0300

Hi,

On 2020-7-23, at 10:34, Gorry Fairhurst <[email-masked]> wrote:
> These methods often hash based on port, IP, and maybe other fields to select a queue - There are a finite set of queues, a rehash results in the traffic moving queue ... to chooses a different path or queue within the device. This mapping is statistical, this matters more if the multiplexing is low and a port change results in unbalance across quques/paths.

I agree this is mostly a concern for low-mux'ing cases when a single rehash can create significant imbalance. How common are such deployments, and how much of a problem is such a temporary imbalance (the CC will adjust quickly). Esp. compared to forcing slow-start after every NAT rebind.

Lars

---

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 23 Jul 2020 09:31:42 +0100

On 23/07/2020 08:42, Lars Eggert wrote:
> I agree this is mostly a concern for low-mux'ing cases when a single rehash can create significant imbalance. How common are such deployments,
Sounds like interesting research for PANRG: How could we obtain that 
data for the general Internet? Specifically do you know of measurement 
campaigns that looked at this across different types of network path?
> and how much of a problem is such a temporary imbalance (the CC will adjust quickly).

Maybe, or is it true?  The reaction and impact depends on how QUIC's 
congestion controller deals with path changes (significant changes in 
capacity) esp when accompanined by RTT changes.

I could  suggest a test case where flows are divided in the network 
between two paths - one shorter RTT, one longer RTT and more 
constrained. A change in path results in traffic using wrong path 
assumptions. QUIC's Loss Recovery and Congestion reaction are timer 
based, and this timing information is wrong after a change, and the CC 
decision is also wrong. TCP wouldn't have done that.

> Esp. compared to forcing slow-start after every NAT rebind.
>
> Lars

If you say you wish to avoid slow-start after NAPT rebind, then I think 
this is a significant change to CC behviour relative to other IETF 
transport protocols, and is not similar to what Reno-TCP would do.

If you only reset QUIC's RTT estimator, that could be sufficent, 
especially if the port change didn't result in changes in capacity. It 
does however stand the risk that CC overshoots the capacity and the flow 
might suffer more. Reseting both until you confirm the new transport 
path seems safer in a PS, and is what the Recovery Draft currently says.

However, once the RTT is reset following this port change, a new path 
RTT is then established by the QUIC CC, I'd expect that the CC can then 
make informed decisions about what to do using the observed RTT. That 
could be slkow start. It would also seem reasonable that an endpoint 
that knows this RTT is the same as previous could then use this as a 
reasonable sign to become more aggressive than slow-start, perhaps 
restoring the CC state. To me, that sounds a lot like the case where a 
congestion-controller "thinks" it has evidence where there might be more 
capacity, but the endpoint isn't sure (as in Section 7.10, albeit in 
that case for other reasons... but there still needs some safety when 
there is significant path change). This sounds like a way the IETF could 
examine, and if we figure out the details, I expect this might work well 
for QUIC?

Gorry

---

From: Lars Eggert <[email-masked]>
Date: Thu, 23 Jul 2020 11:43:01 +0300

Hi,

On 2020-7-23, at 11:31, Gorry Fairhurst <[email-masked]> wrote:
> If you say you wish to avoid slow-start after NAPT rebind, then I think this is a significant change to CC behviour relative to other IETF transport protocols, and is not similar to what Reno-TCP would do.

how so? Current IETF transport protocols don't even survive a NAT rebind.

> If you only reset QUIC's RTT estimator, that could be sufficent, especially if the port change didn't result in changes in capacity. It does however stand the risk that CC overshoots the capacity and the flow might suffer more. Reseting both until you confirm the new transport path seems safer in a PS, and is what the Recovery Draft currently says.

Actually, you should have an RTT sample from a new path anyway, since you need to do a PATH_CHALLENGE/PATH_RESPONSE exchange.

In terms of CC overshoot, if that happens, it will lead to drops/marks being reported within one RTT, which will cause the right thing to happen.

> However, once the RTT is reset following this port change, a new path RTT is then established by the QUIC CC, I'd expect that the CC can then make informed decisions about what to do using the observed RTT. That could be slkow start. It would also seem reasonable that an endpoint that knows this RTT is the same as previous could then use this as a reasonable sign to become more aggressive than slow-start, perhaps restoring the CC state. To me, that sounds a lot like the case where a congestion-controller "thinks" it has evidence where there might be more capacity, but the endpoint isn't sure (as in Section 7.10, albeit in that case for other reasons... but there still needs some safety when there is significant path change). This sounds like a way the IETF could examine, and if we figure out the details, I expect this might work well for QUIC?

It's of course possible to invent more clever schemes to determine whether CC/RTT state should be reused after a port change. But my belief at the moment is that reuse would not be catastrophic. Sure, there will be cases where CC overshoots, but I am unconvinced this will be a serious/frequent issue.

Lars

PS: I'll pause myself for a bit, to let others respond.

---

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 23 Jul 2020 10:10:58 +0100

Hi,

> how so? Current IETF transport protocols don't even survive a NAT rebind.
They all slow-start.
> Actually, you should have an RTT sample from a new path anyway, since you need to do a PATH_CHALLENGE/PATH_RESPONSE exchange.
Right.
> In terms of CC overshoot, if that happens, it will lead to drops/marks being reported within one RTT, which will cause the right thing to happen.
Not that fast in all cases?
> PS: I'll pause myself for a bit, to let others respond.

I'd like that discussion also... this is new & interesting...

Gorry

---

From: Christian Huitema <[email-masked]>
Date: Thu, 23 Jul 2020 11:46:57 -0700

> I agree this is mostly a concern for low-mux'ing cases when a single rehash can create significant imbalance. How common are such deployments, and how much of a problem is such a temporary imbalanc…

Gorry, Lars, where can we find data on the NAT behavior and the relation
between NAT rebinding and routing paths? In home routers, NAT rebinding
typically only change if the session is quiet for some time. Do we
observe a different behavior with CGNAT?

-- Christian Huitema

---

From: Jana Iyengar <[email-masked]>
Date: Thu, 23 Jul 2020 14:02:06 -0700

I'm happy with the resolution that Ted proposed and Lars wrote up in PR 3945
<https://github.com/quicwg/base-drafts/pull/3945>.

We should not forget that endpoints will do what they choose to do on this
particular issue. It's perfectly reasonable to assume that port changes are
infrequent and do not reflect a path change commonly. In the rare case that
it happens and in the rarer case that it is in fact a path change, both
congestion controllers and RTT estimators are adaptive. The text in the PR
captures this possibility. That reflects reality and is an adequately
cautious recommendation, IMO.

On Thu, Jul 23, 2020 at 11:47 AM Christian Huitema <[email-masked]>
wrote:

> On 2020-7-23, at 10:34, Gorry Fairhurst <[email-masked]> <[email-masked]> wrote:
>
> typically only change if the session is quiet for some time. Do we observe
> a different behavior with CGNAT?
>
> -- Christian Huitema
>

---

From: Gorry Fairhurst <[email-masked]>
Date: Fri, 24 Jul 2020 08:30:31 +0100

On 23/07/2020 22:02, Jana Iyengar wrote:
> I'm happy with the resolution that Ted proposed and Lars wrote up in 
> PR 3945 <https://github.com/quicwg/base-drafts/pull/3945>.
>
> We should not forget that endpoints will do what they choose to do on 
> this particular issue. It's perfectly reasonable to assume that port 
> changes are infrequent and do not reflect a path change commonly. In 
> the rare case that it happens and in the rarer case that it is in fact 
> a path change, both congestion controllers and RTT estimators are 
> adaptive. The text in the PR captures this possibility. That reflects 
> reality and is an adequately cautious recommendation, IMO.
>
As you expect I don't agree this is cautious: optimising for an 
infrequent/rare case is not cautious, it introduces more chance of 
undesriable side effects on paths that actually are different.

There seems to me to be little impact in re-initialising the RTT 
estimator, there's an initial handshake for the new path from which this 
can be initialised.

Christian: I also would love to see data about the frequency and 
pathology, but don't know of any.

Gorry

> On Thu, Jul 23, 2020 at 11:47 AM Christian Huitema 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>>     On 2020-7-23, at 10:34, Gorry Fairhurst<[email-masked]>  <mailto:[email-masked]..uk>  wrote:
>     Gorry, Lars, where can we find data on the NAT behavior and the
>     relation between NAT rebinding and routing paths? In home routers,
>     NAT rebinding typically only change if the session is quiet for
>     some time. Do we observe a different behavior with CGNAT?
>
>     -- Christian Huitema
>

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 24 Jul 2020 07:47:03 +0000

Hi,

So if I understand this correctly we have a couple of different reasons for
reasons for the port change to occur.

NAT binding times out: In this case the CC state should also have been aged as
the QUIC connection has not sent anything for many seconds. I would think a
minimal of 5 seconds, likely at least 30 seconds of inactivity for an
established QUIC connection as it will have gotten the NAT into a bi-directional 
UDP flow state, rather than a one of request response state, like for NATs with
DNS binding recovery optimizations.

NAT binding lost in restart or crash of NAT device: In this case it is likely
that an active connection have lost several packets on the old port before the
migration happens. Will those losses be represented in the migrated CC state? 
An
semi active connection may have not lost any packets and in worst case had a
fairly large window, then went quite some few seconds will the NAT device
recovers and thus a limited aging of CC state could have occurred. 

NAT lost binding to resource exhaustion: In case of an attack or simply
overwhelming amounts of flows the NAT exhaust its resources and starts recycling
the bindings that had longest time since last use. That could in worst case
cause frequent rebindings. I would say this is broken NAT device that is better
of refusing bindings in this scenario than making existing bindings breaking. 

Change of attachment point behind a CGNAT: A node could potentially change its
local IP address but stay behind the same CGNAT. The NAT will create new binding
as it doesn't know that this is the same device. This represents an actual path
change. It doesn't appear the most likely scenario, but could occur for example
if I move from my home wifi to my frindly neighbours wifi which I also attach
and we use the same ISP. 

Does anyone have a scenario where a port change would actually occurr when the
QUIC conenction is transmitting at any significnat rate and the port change
would not incurr packet loss or seconds of the path being blocked? 

To me it appears that the scenarios I can think of all would result in
significnat reduction of allowable transmission rate anyway. Have I missed
something relevant here? 

Cheers

Magnus Westerlund

On Thu, 2020-07-23 at 14:02 -0700, Jana Iyengar wrote:
> I'm happy with the resolution that Ted proposed and Lars wrote up in PR 3945.
> 
> infrequent and do not reflect a path change commonly. In the rare case that it
> happens and in the rarer case that it is in fact a path change, both
> captures this possibility. That reflects reality and is an adequately cautious
> recommendation, IMO.
> 
> > > I agree this is mostly a concern for low-mux'ing cases when a single
> > > rehash can create significant imbalance. How common are such deployments,
> > > and how much of a problem is such a temporary imbalance (the CC will
> > > adjust quickly). Esp. compared to forcing slow-start after every NAT
> > > rebind.
> > 
> > typically only change if the session is quiet for some time. Do we observe a
> > different behavior with CGNAT? 
> > -- Christian Huitema
-- 
Cheers

Magnus Westerlund 

----------------------------------------------------------------------
Networks, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Kuhn Nicolas <[email-masked]>
Date: Fri, 24 Jul 2020 09:41:04 +0000

De : QUIC <[email-masked]> De la part de Gorry Fairhurst
Envoyé : vendredi 24 juillet 2020 09:31
À : Jana Iyengar <[email-masked]>; Christian Huitema <[email-masked]>
Cc : Lars Eggert <[email-masked]>; QUIC WG <[email-masked]>; Martin Thomson <[email-masked]>
Objet : Re: Consensus call for Late-Stage documents, pre-IETF 108 edition

On 23/07/2020 22:02, Jana Iyengar wrote:
I'm happy with the resolution that Ted proposed and Lars wrote up in PR 3945<https://github.com/quicwg/base-drafts/pull/3945>.

We should not forget that endpoints will do what they choose to do on this particular issue. It's perfectly reasonable to assume that port changes are infrequent and do not reflect a path change commonly. In the rare case that it happens and in the rarer case that it is in fact a path change, both congestion controllers and RTT estimators are adaptive. The text in the PR captures this possibility. That reflects reality and is an adequately cautious recommendation, IMO.

As you expect I don't agree this is cautious: optimising for an infrequent/rare case is not cautious, it introduces more chance of undesriable side effects on paths that actually are different.

There seems to me to be little impact in re-initialising the RTT estimator, there's an initial handshake for the new path from which this can be initialised.

[NK] There are cases where resuming the connection with previously stored data rate is very useful (see the 0-RTT draft for SATCOM communications use case). However, there are risks that network conditions have changed (this may be truer for the 0-RTT  case than the NAT rebind case). How about a recommendation for a “safe jumping back to previously stored data rate” ? We have proposed a strawman algorithm in the 0-RTT draft (in the Appendix) that could be relevant in this case.

My 2cts,

Nico

Christian: I also would love to see data about the frequency and pathology, but don't know of any.

Gorry
On Thu, Jul 23, 2020 at 11:47 AM Christian Huitema <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

On 2020-7-23, at 10:34, Gorry Fairhurst <[email-masked]><mailto:[email-masked]..uk> wrote:

Gorry, Lars, where can we find data on the NAT behavior and the relation between NAT rebinding and routing paths? In home routers, NAT rebinding typically only change if the session is quiet for some time. Do we observe a different behavior with CGNAT?

-- Christian Huitema

---

From: Ian Swett <[email-masked]>
Date: Fri, 24 Jul 2020 14:01:22 -0400

I'm happy with the direction of the PR.

I don't think it's possible to compare this to TCP, since in TCP if the NAT
hole is dropped, the connection is closed.

Magnus, I'm not sure change of attachment behind a CGN is very likely based
on where I've seen CGN deployed.  Also, it'd require migration from Wifi to
Wifi, which is a lot less common than Wifi to Cell or Cell to Wifi.  But
even so, two physically adjacent wireless networks on the same ISP probably
have more in common than not.

There's a very real cost to re-entering slow-start, not just in terms of
time, but also in terms of the packet loss and bufferbloat it tends to
cause.  Congestion controllers are virtually always sending at the wrong
rate, so this comes down to whether continuing with the existing estimates
are better than starting over.  In the case of a port change, I think it's
a very good bet that the existing estimates are better.

One additional note: Clients MUST change Connection ID if they
intentionally migrate, so a server can use the lack of CID change as a
signal that it was likely an NAT or other unintended path change.

Ian

On Fri, Jul 24, 2020 at 3:47 AM Magnus Westerlund <magnus.westerlund=
[email-masked]> wrote:

> this
> relation
> <+46%2010%20714%2082%2087>
> <+46%2073%20094%2090%2079>

---

From: Lucas Pardue <[email-masked]>
Date: Wed, 29 Jul 2020 13:55:44 +0100

Hi folks,

The consensus call has now ended.

We saw some pushback on the proposed resolution to #3842. Discussion on an
alternative proposal is continuing so we'll run this issue through the
Late-Stage process again.

There appears to be no pushback on the other issues, so consensus is
declared.

Kind regards
Lars, Lucas and Mark
QUIC WG Chairs

---

From: Lars Eggert <[email-masked]>
Date: Wed, 29 Jul 2020 16:43:27 +0300

On 2020-7-24, at 21:01, Ian Swett <ianswett=[email-masked]> wrote:
> One additional note: Clients MUST change Connection ID if they intentionally migrate, so a server can use the lack of CID change as a signal that it was likely an NAT or other unintended path change.

If I modified #3842 to take this into account, would that address people's concerns? Something like:

"...unless the only change is the other endpoint's port number ***and the connection ID did not change***" (new text between ***)

Thanks,
Lars