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

[Ted Hardie <[e-mail]>]

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 <[e-mail]> wrote:

> Hi,
>
> On 2020-7-22, at 6:11, Eric Rescorla <[e-mail]> 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
>