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

[Gorry Fairhurst <[e-mail]>]

On 23/07/2020 08:42, Lars Eggert wrote:
> Hi,
>
> On 2020-7-23, at 10:34, Gorry Fairhurst <[e-mail]> 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,
Sounds like interesting research for PANRG: How could we obtain that 
data for the general Internet? Specifically do you know of measurement 
campaigns that looked at this across different types of network path?
> and how much of a problem is such a temporary imbalance (the CC will adjust quickly).

Maybe, or is it true?  The reaction and impact depends on how QUIC's 
congestion controller deals with path changes (significant changes in 
capacity) esp when accompanined by RTT changes.

I could  suggest a test case where flows are divided in the network 
between two paths - one shorter RTT, one longer RTT and more 
constrained. A change in path results in traffic using wrong path 
assumptions. QUIC's Loss Recovery and Congestion reaction are timer 
based, and this timing information is wrong after a change, and the CC 
decision is also wrong. TCP wouldn't have done that.

> Esp. compared to forcing slow-start after every NAT rebind.
>
> Lars

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.

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.

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?

Gorry