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

[Lars Eggert <[e-mail]>]

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