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

[Kuhn Nicolas <[e-mail]>]

De : QUIC <[e-mail]> De la part de Gorry Fairhurst
Envoyé : vendredi 24 juillet 2020 09:31
À : Jana Iyengar <[e-mail]>; Christian Huitema <[e-mail]>
Cc : Lars Eggert <[e-mail]>; QUIC WG <[e-mail]>; Martin Thomson <[e-mail]>
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 <[e-mail]<mailto:[e-mail]>> wrote:

On 7/23/2020 12:42 AM, Lars Eggert wrote:

Hi,



On 2020-7-23, at 10:34, Gorry Fairhurst <[e-mail]><mailto:[e-mail]..uk> 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.



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