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

[Magnus Westerlund <[e-mail]>]

Hi,

So if I understand this correctly we have a couple of different reasons for
reasons for the port change to occur.

NAT binding times out: In this case the CC state should also have been aged as
the QUIC connection has not sent anything for many seconds. I would think a
minimal of 5 seconds, likely at least 30 seconds of inactivity for an
established QUIC connection as it will have gotten the NAT into a bi-directional 
UDP flow state, rather than a one of request response state, like for NATs with
DNS binding recovery optimizations.

NAT binding lost in restart or crash of NAT device: In this case it is likely
that an active connection have lost several packets on the old port before the
migration happens. Will those losses be represented in the migrated CC state? 
An
semi active connection may have not lost any packets and in worst case had a
fairly large window, then went quite some few seconds will the NAT device
recovers and thus a limited aging of CC state could have occurred. 

NAT lost binding to resource exhaustion: In case of an attack or simply
overwhelming amounts of flows the NAT exhaust its resources and starts recycling
the bindings that had longest time since last use. That could in worst case
cause frequent rebindings. I would say this is broken NAT device that is better
of refusing bindings in this scenario than making existing bindings breaking. 

Change of attachment point behind a CGNAT: A node could potentially change its
local IP address but stay behind the same CGNAT. The NAT will create new binding
as it doesn't know that this is the same device. This represents an actual path
change. It doesn't appear the most likely scenario, but could occur for example
if I move from my home wifi to my frindly neighbours wifi which I also attach
and we use the same ISP. 

Does anyone have a scenario where a port change would actually occurr when the
QUIC conenction is transmitting at any significnat rate and the port change
would not incurr packet loss or seconds of the path being blocked? 

To me it appears that the scenarios I can think of all would result in
significnat reduction of allowable transmission rate anyway. Have I missed
something relevant here? 


Cheers

Magnus Westerlund


On Thu, 2020-07-23 at 14:02 -0700, Jana Iyengar wrote:
> I'm happy with the resolution that Ted proposed and Lars wrote up in PR 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.
> 
> On Thu, Jul 23, 2020 at 11:47 AM Christian Huitema <[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]> 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
-- 
Cheers

Magnus Westerlund 


----------------------------------------------------------------------
Networks, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  [phone]
Torshamnsgatan 23           | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------