Re: ECN in QUIC connection migration

[Eric Kinnear <[e-mail]>]

Hi Ingemar, 

This generally looks good to me!
A few questions and observations: 

> There are two unique cases:
> 
> 	• ECN capability check successful at initial connection setup
> 	• ECN capability check failed at initial connection setup

Are these actually any different in terms of action taken by an endpoint?
It seems like on the new network path the endpoint would go through the same process of: (a) verify ECN capability and if successful to whatever degree then (b) run the rest of the ECN machinery as appropriate.

In other words, as long as you allow people to start using ECN upon migration (in other words, to allow starting it after the initial connection establishment), then the specifics for ECN with migration is essentially one statement, which is “do the ECN process on each new network path that you use”. 

> Connection migration has impact on the number of reported CE marked packets. A new connection state with new congestion control state and ECN counters is instantiated at the sender and receiver. The ECN counters MUST start from zero again.

This seems fine to me, it’s inline with the rest of the congestion control/loss recovery state that also needs to be reset for the new path. 

Given that each migration requires at least one exchange of packets at the beginning (at the very least for address validation from the side of the endpoint that didn’t migrate), it seems like that’s an excellent moment to mark the packets and perform the ECN capability detection. Those packets are also likely padded, etc. similar to initial packets since they’re on a previously unused network path. 

I think the current proposed requirement of just using the “first” packets and marking those is sufficient (and good to avoid any requirement as to which frames are contained in those packets), since we are always exchanging packets in both directions immediately after migration. 

This has the added benefit such that any endpoint “probing” possible network paths could include the bits necessary to detect ECN capability on the path being probed, so it could even know before migrating whether or not it would be able to use ECN on that new path. 

Thanks,
Eric



> On Feb 1, 2018, at 3:07 AM, Ingemar Johansson S <[e-mail]> wrote:
> 
> Hi
> I have written up different aspects of connection migration and how it plays with ECN.
> https://github.com/quicwg/base-drafts/wiki/ECN-in-QUIC#transport-draft-connection-migration <https://github.com/quicwg/base-drafts/wiki/ECN-in-QUIC#transport-draft-connection-migration>
>  
> A caveat.. I am a bit unsure about the definition of connection migration . My interpretation is that a client moves to a new IP address due to e.g. a NAT rebind or switch from WiFi to cellular, right ?. Is a new connection instantiated at a connection migration ? 
>  
> /Ingemar
>  
> ==================================
> Ingemar Johansson  M.Sc.
> Master Researcher
>  
> Ericsson Research
> Network Protocols & E2E Performance
> Labratoriegränd 11
> 971 28, Luleå, Sweden
> Phone [phone]
> SMS/MMS [phone]
> [e-mail] <mailto:[e-mail]>
> www.ericsson.com <x-msg://316/www.ericsson.com>
>  
>                  You can't start a fire
>   Worrying 'bout your little world falling apart
>                Bruce Springsteen
> ==================================