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

[Gorry Fairhurst <[e-mail]>]

Hi,

On 23/07/2020 09:43, Lars Eggert wrote:
> Hi,
>
> On 2020-7-23, at 11:31, Gorry Fairhurst <[e-mail]> wrote:
>> If you say you wish to avoid slow-start after NAPT rebind, then I think this is a significant change to CC behviour relative to other IETF transport protocols, and is not similar to what Reno-TCP would do.
> how so? Current IETF transport protocols don't even survive a NAT rebind.
They all slow-start.
>
>> If you only reset QUIC's RTT estimator, that could be sufficent, especially if the port change didn't result in changes in capacity. It does however stand the risk that CC overshoots the capacity and the flow might suffer more. Reseting both until you confirm the new transport path seems safer in a PS, and is what the Recovery Draft currently says.
> Actually, you should have an RTT sample from a new path anyway, since you need to do a PATH_CHALLENGE/PATH_RESPONSE exchange.
Right.
>
> In terms of CC overshoot, if that happens, it will lead to drops/marks being reported within one RTT, which will cause the right thing to happen.
Not that fast in all cases?
>> However, once the RTT is reset following this port change, a new path RTT is then established by the QUIC CC, I'd expect that the CC can then make informed decisions about what to do using the observed RTT. That could be slkow start. It would also seem reasonable that an endpoint that knows this RTT is the same as previous could then use this as a reasonable sign to become more aggressive than slow-start, perhaps restoring the CC state. To me, that sounds a lot like the case where a congestion-controller "thinks" it has evidence where there might be more capacity, but the endpoint isn't sure (as in Section 7.10, albeit in that case for other reasons... but there still needs some safety when there is significant path change). This sounds like a way the IETF could examine, and if we figure out the details, I expect this might work well for QUIC?
> It's of course possible to invent more clever schemes to determine whether CC/RTT state should be reused after a port change. But my belief at the moment is that reuse would not be catastrophic. Sure, there will be cases where CC overshoots, but I am unconvinced this will be a serious/frequent issue.
>
> Lars
>
> PS: I'll pause myself for a bit, to let others respond.

I'd like that discussion also... this is new & interesting...

Gorry