MIN_RTT management

[gorryfair]

So, I understand that min_RTT is maintained per path as the minimum RTT.

I foresee paths that persist for long periods and where the set of network devices forming the can path change, and hence the min_RTT can be "ridiculously" small concerned to the actual value had it been measured recently. I don't much like that min_RTT is never raised.

The solution could be simple. Re-initialise min_RTT from the RTT sample periodically. How often to reset is not critical, but needs to be reasonably often - I suggest every 600 secs. (I'd be OK with other numbers, this is the default path state timeout in RFC1981).

[gorryfair]

Related to #2908, but this is more than editorial.

[janaiyengar]

@gorryfair : Having thought about this some more, I don't think we should be doing anything here.

We need to define the constraints around min_rtt based on its use in the recovery document. As it stands, this document uses min_rtt for rejecting RTT samples that are too small. The cost of having a min_rtt that is too low is that the endpoint might allow for the SRTT to be smaller when the peer is incorrectly sending ack-delays that are too large.

We knew this problem when we chose to use ack-delays in the SRTT computation and we decided to not solve it then. I don't think we need to solve it now.

[ianswett]

After more discussion, I think Jana's right and we should close this with no action. The min_rtt in QUIC recovery is used for a very specific purpose(preventing 'silly' SRTTs due to ack_delay) and not meant for other purposes.

[gorryfair]

I don't agree that the method is robust to path changes that result in a larger RTT. I can read the latest draft and see if the comment still applies.

[huitema]

The corresponding mechanism in BBR uses a 10 seconds interval. Quite different from the 600 seconds mentioned above.

[larseggert]

Discussed in ZRH. Proposed resolution is to close with no action. Possible new Editorial PR to explain that min_rtt is only used to provide a safety feature and having a potentially stale value is therefore not terrible.

[gorryfair]

OK - I missed the part of the meeting discussing that: I concur that if QUIC never uses this variable for other things, then the current specific use of min_rtt in the latest rev does note the problem above.

[martinthomson]

I'm going to re-open this so that we can let the process run, but thanks for acknowledging this Gorry.