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

[Gorry Fairhurst <[e-mail]>]

See below,

On 23/07/2020 08:22, Lars Eggert wrote:
> Hi,
>
> On 2020-7-23, at 10:09, Gorry Fairhurst <[e-mail]> wrote:
>> I thought the point that NAPT was common point had been discussed in QUIC before, and was noted that there are devices on path that change the forwrading path and hence congestion conditions based on the flow's port value. ECMP is a not that uncommon example, other load ballancing can also change the path.
> but with ECMP, SFQ and similar schemes, the intent it spread the load equally over a set of candidate paths.
>   So, assuming some level of utilization, all those candidate paths should have more-or-less similar path characteristics?

If you consider all paths equal, then sure, but how can you make that 
assumption?

If you assume this can only happen when the chosen paths have similar 
condictions, then I'd have to agree - but how can it be assumed that 
paths have equivalent unused capacity?

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 that in general, a path change should cause a CC state reset, but in this specific case, I think we can make some assumptions (like the above) that may make it OK to not do that.
>
> Lars

I still think this is a new CC decision, and the charter explicitly says 
that this version of QUIC will not make new congestion controllers.

Gorry