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

[Martin Thomson <[e-mail]>]

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:
> Sounds good to me too.
> 
> -- Christian Huitema
> 
> On 7/22/2020 9:44 AM, Eric Rescorla wrote:
> > Ted's proposal would be acceptable to me.
> > 
> > -Ekr
> > 
> > 
> > On Wed, Jul 22, 2020 at 7:48 AM Ted Hardie <[e-mail]> 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: 
> >> 
> >> 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