Subject: ECN in QUIC connection migration

From: Ingemar Johansson S <[email-masked]>
Date: Thu, 1 Feb 2018 11:07:04 +0000

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

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 +46-1071 43042
SMS/MMS +46-73 078 3289
[email-masked]<mailto:[email-masked]>
www.ericsson.com

                 You can't start a fire
  Worrying 'bout your little world falling apart
               Bruce Springsteen
==================================

---

From: Eric Kinnear <[email-masked]>
Date: Thu, 01 Feb 2018 15:01:34 -0800

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 <[email-masked]> wrote:
> 
> Hi
> 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>
>  
> [email-masked] <mailto:[email-masked]>
> www.ericsson.com <x-msg://316/www.ericsson.com>
>  
>                  You can't start a fire

---

From: Ingemar Johansson S <[email-masked]>
Date: Fri, 2 Feb 2018 14:40:49 +0000

Hi
Thanks for the comments.
You are right, eventually the specifics around ECN capability at connection migration should be very simple. I chose to overspecify the text, hopefully to make it sufficiently clear that byte counters should do the job just fine.

/Ingemar

From: [email-masked] [mailto:[email-masked]]
Sent: den 2 februari 2018 00:02
To: Ingemar Johansson S <[email-masked]>
Cc: QUIC WG <[email-masked]>; Ian Swett <[email-masked]>; Lubashev, Igor <[email-masked]>; Christian Huitema <[email-masked]>; De Schepper, Koen (Nokia - BE/Antwerp) <[email-masked]>
Subject: Re: ECN in QUIC connection migration

Hi Ingemar,

Thanks,
Eric

On Feb 1, 2018, at 3:07 AM, Ingemar Johansson S <[email-masked]<mailto:[email-masked]>> wrote:

Hi

/Ingemar

Ericsson Research
Network Protocols & E2E Performance
Labratoriegränd 11
971 28, Luleå, Sweden
Phone +46-1071 43042
SMS/MMS +46-73 078 3289
[email-masked]<mailto:[email-masked]>
www.ericsson.com<x-msg://316/www.ericsson.com>

                 You can't start a fire

---

From: "De Schepper, Koen (Nokia - BE/Antwerp)" <[email-masked]>
Date: Fri, 2 Feb 2018 14:44:24 +0000

Hi Ingemar,

I also read again through the document, and had following comments:

I replaced:
“The ACK_ECN frame is used to convey ACKs when the ECN capability exchange concludes that ECN should be used for the given connection.”
Originally it sounds as if the counters are not echoed anymore if the ECN capability check fails. I assume this was not the intention, but if it is: First, we don’t have a protocol or decision point defined when that condition is met (sender should let the receiver know in the next packet), and second, I would always send the echo, as we might “try again later (with another ECT?)”, or might decide to use the ECN bits differently later.

I also changed the text around the connection migration, I think before Eric reviewed it. I made it such that every new path creates a new connection state with an initialized congestion control state and ECN counters (at least ECN counters reset to 0s). Not sure if this matches with the other sections in the QUIC draft.

I also had the thought whether it was really needed to have the 2 cases. I agree we should simplify, by just starting over and doing the check unconditionally whether it was successful or not in a previous path.

Regards,
Koen.

Sent: Friday, February 2, 2018 12:02 AM

Hi Ingemar,

Thanks,
Eric

Hi

/Ingemar

Ericsson Research

                 You can't start a fire

---

From: Ingemar Johansson S <[email-masked]>
Date: Fri, 9 Feb 2018 07:34:46 +0000

Hi Eric, Koen + others

Thanks for the comments and the update. A question to the rest of the audience, does the presented text explain sufficiently enough how ECN works with connection migration ?
https://github.com/quicwg/base-drafts/wiki/ECN-in-QUIC#transport-draft-connection-migration

/Ingemar

From: De Schepper, Koen (Nokia - BE/Antwerp) [mailto:[email-masked]]
Sent: den 2 februari 2018 15:44
To: [email-masked]; Ingemar Johansson S <[email-masked]>
Cc: QUIC WG <[email-masked]>; Ian Swett <[email-masked]>; Lubashev, Igor <[email-masked]>; Christian Huitema <[email-masked]>
Subject: RE: ECN in QUIC connection migration

Hi Ingemar,

I replaced:

Regards,
Koen.

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Friday, February 2, 2018 12:02 AM
To: Ingemar Johansson S <[email-masked]<mailto:[email-masked]>>
Cc: QUIC WG <[email-masked]<mailto:[email-masked]>>; Ian Swett <[email-masked]<mailto:[email-masked]>>; Lubashev, Igor <[email-masked]<mailto:[email-masked]>>; Christian Huitema <[email-masked]<mailto:[email-masked]>>; De Schepper, Koen (Nokia - BE/Antwerp) <[email-masked]<mailto:[email-masked]>>
Subject: Re: ECN in QUIC connection migration

Hi Ingemar,

Thanks,
Eric

Hi

/Ingemar

Ericsson Research

                 You can't start a fire

---

From: Mirja Kühlewind <[email-masked]>
Date: Mon, 12 Feb 2018 16:26:21 +0100

Hi Ingemar,

two points. 

I think it would be good to be as explicit as possible here, therefore I would prefer if an endpoint that knows that it can not access the ECN IP bits indicates this directly in the handshake. In this case no further testing is needed.

Further, the path testing itself is independent of QUIC and can be used for any protocol. Moreover, it’s more complicated than just testing ECT. I guess the general advice here is to remember which codepoints were send and compare this to the feedback provided. If discrepancies are observed that indicate that a middlebox has changed these bits, all packets should be marked as no-ECT (while additional testing MAY be performed at any later point in time). However, how exactly this testing should look like, should not be specified in this doc (but more generally).

Mirja

> Am 09.02.2018 um 08:34 schrieb Ingemar Johansson S <[email-masked]>:
> 
> Hi Eric, Koen + others
>  
> [email-masked]
> www.ericsson.com
>  
>                  You can't start a fire

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Mon, 12 Feb 2018 07:42:05 -0800

I haven’t followed the ECN discussion very closely, but I miss a discussion
of possible abuse scenarios and how to avoid them.

On 12 February 2018 at 16.26.32, Mirja Kühlewind (
[email-masked]) wrote:

Hi Ingemar,

two points.

I think it would be good to be as explicit as possible here, therefore I
would prefer if an endpoint that knows that it can not access the ECN IP
bits indicates this directly in the handshake. In this case no further
testing is needed.

Further, the path testing itself is independent of QUIC and can be used for
any protocol. Moreover, it’s more complicated than just testing ECT. I
guess the general advice here is to remember which codepoints were send and
compare this to the feedback provided. If discrepancies are observed that
indicate that a middlebox has changed these bits, all packets should be
marked as no-ECT (while additional testing MAY be performed at any later
point in time). However, how exactly this testing should look like, should
not be specified in this doc (but more generally).

Mirja

> Thanks for the comments and the update. A question to the rest of the
audience, does the presented text explain sufficiently enough how ECN works
with connection migration ?
> Cc: QUIC WG <[email-masked]>; Ian Swett <[email-masked]>; Lubashev,
Igor <[email-masked]>; Christian Huitema <[email-masked]>
> “The ACK_ECN frame is used to convey ACKs when the ECN capability
exchange concludes that ECN should be used for the given connection.”
> Originally it sounds as if the counters are not echoed anymore if the ECN
capability check fails. I assume this was not the intention, but if it is:
First, we don’t have a protocol or decision point defined when that
condition is met (sender should let the receiver know in the next packet),
and second, I would always send the echo, as we might “try again later
(with another ECT?)”, or might decide to use the ECN bits differently
later.
>
> I also changed the text around the connection migration, I think before
Eric reviewed it. I made it such that every new path creates a new
connection state with an initialized congestion control state and ECN
counters (at least ECN counters reset to 0s). Not sure if this matches with
the other sections in the QUIC draft.
>
> I also had the thought whether it was really needed to have the 2 cases.
I agree we should simplify, by just starting over and doing the check
unconditionally whether it was successful or not in a previous path.
> Cc: QUIC WG <[email-masked]>; Ian Swett <[email-masked]>; Lubashev,
Igor <[email-masked]>; Christian Huitema <[email-masked]>; De
Schepper, Koen (Nokia - BE/Antwerp) <[email-masked]>
> 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.
>
> 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 ?

---

From: Mirja Kühlewind <[email-masked]>
Date: Mon, 12 Feb 2018 16:43:36 +0100

What do you mean by abuse scenarios? However, I would guess again that this is not a quic specific discussion and should probably rather happen in tsvwg which is the group that is maintain ECN in general.

Mirja

> Am 12.02.2018 um 16:42 schrieb Mikkel Fahnøe Jørgensen <[email-masked]>:
> 
> I haven’t followed the ECN discussion very closely, but I miss a discussion of possible abuse scenarios and how to avoid them.
> 
> On 12 February 2018 at 16.26.32, Mirja Kühlewind ([email-masked]) wrote:
> 
>> Hi Ingemar, 
>> 
>> two points.  
>>

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Mon, 12 Feb 2018 07:54:53 -0800

I don’t know enough about ECN to have a qualified opinion, but I mean that,
for example, someone on the path might make a false impression of the
available bandwidth. It may be a general ECN discussion but I’d like to
know how it affects security of QUIC if made mandatory, just like there are
other sections in QUIC transport on potential attacks to be aware of.

http://web.cs.ucla.edu/~todd/research/sigcomm11.pdf
http://ieeexplore.ieee.org/document/6993126/

Kind Regards,
Mikkel Fahnøe Jørgensen

On 12 February 2018 at 16.43.43, Mirja Kühlewind (
[email-masked]) wrote:

What do you mean by abuse scenarios? However, I would guess again that this
is not a quic specific discussion and should probably rather happen in
tsvwg which is the group that is maintain ECN in general.

Mirja

>
> I haven’t followed the ECN discussion very closely, but I miss a
discussion of possible abuse scenarios and how to avoid them.
>>
>> Further, the path testing itself is independent of QUIC and can be used
for any protocol. Moreover, it’s more complicated than just testing ECT. I
>> > Cc: QUIC WG <[email-masked]>; Ian Swett <[email-masked]>;
Lubashev, Igor <[email-masked]>; Christian Huitema <[email-masked]>

>> > Originally it sounds as if the counters are not echoed anymore if the
ECN capability check fails. I assume this was not the intention, but if it
is: First, we don’t have a protocol or decision point defined when that
condition is met (sender should let the receiver know in the next packet),
and second, I would always send the echo, as we might “try again later
(with another ECT?)”, or might decide to use the ECN bits differently
later.
>> >
>> > I also changed the text around the connection migration, I think
before Eric reviewed it. I made it such that every new path creates a new
connection state with an initialized congestion control state and ECN
counters (at least ECN counters reset to 0s). Not sure if this matches with
the other sections in the QUIC draft.
>> >
>> > I also had the thought whether it was really needed to have the 2
cases. I agree we should simplify, by just starting over and doing the
check unconditionally whether it was successful or not in a previous path.
>> > Cc: QUIC WG <[email-masked]>; Ian Swett <[email-masked]>;
Lubashev, Igor <[email-masked]>; Christian Huitema <[email-masked]>;
De Schepper, Koen (Nokia - BE/Antwerp) <[email-masked]>

>> > 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.
>> >
>> > 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 ?

---

From: Mirja Kühlewind <[email-masked]>
Date: Mon, 12 Feb 2018 17:04:53 +0100

ECN is an explicit congestion signal that can be used to avoid loss. ECN makes no assumption on how exactly the signal is generated but usually you need some kind of active queue management. The ECN signal is then used by the congestion controller at the sender, similar as loss or other signals are used today. It is the network decision how and when to signal congestion using ECN and the endpoints decision how to exactly react to it.

If the network sets ECN-CE even though there is no congestion it would likely cause a reduction in sending of that flow but it can also just drop some packets to achieve the same. However, as I said this is nothing quic-specific and should be discussed on the tsvwg list instead.

> Am 12.02.2018 um 16:54 schrieb Mikkel Fahnøe Jørgensen <[email-masked]>:
> 
> I don’t know enough about ECN to have a qualified opinion, but I mean that, for example, someone on the path might make a false impression of the available bandwidth. It may be a general ECN discussion but I’d like to know how it affects security of QUIC if made mandatory, just like there are other sections in QUIC transport on potential attacks to be aware of.
> 
> On 12 February 2018 at 16.43.43, Mirja Kühlewind ([email-masked]) wrote:
>

---

From: Ingemar Johansson S <[email-masked]>
Date: Mon, 12 Feb 2018 21:01:49 +0000

Hi

I would say that the worries about endpoints cheating about ECN marks congestion are real old, they have at least been there since I began working with this more than 10 years ago.
But you don’t really need ECN to cheat. From a server perspective you can implement a TCP congestion control module in Linux that just locks CWND to 1500 segments or whatever and you’re done. In a TCP receiver I guess you can generate bogus DSACKs to make the congestion window roll back after a fast retransmit or ?
Problem with this is of course that you cannot completely rule out that you spoil your own bottleneck in the process, so the outcome may well be that you are more likelky to cause more harm to yourself than to others, especially with today’s traffic patterns that is a mix of short and long lived flows.

An interesting side note is that people like Bob Briscoe (and Mirja) spend quite an effort to devise ConEx (RFC6789) as an answer to all these cheating problems, it never gained traction though, at least not so far. But I liked the idea and still like it.

BR
/Ingemar

From: Mikkel Fahnøe Jørgensen [mailto:[email-masked]]
Sent: den 12 februari 2018 16:55
To: Mirja Kühlewind <[email-masked]>
Cc: [email-masked]; QUIC WG <[email-masked]>; Ian Swett <[email-masked]>; Ingemar Johansson S <[email-masked]>; Christian Huitema <[email-masked]>; De Schepper, Koen (Nokia - BE/Antwerp) <[email-masked]>; Lubashev, Igor <[email-masked]>
Subject: Re: ECN in QUIC connection migration

Kind Regards,
Mikkel Fahnøe Jørgensen

On 12 February 2018 at 16.43.43, Mirja Kühlewind ([email-masked]<mailto:[email-masked]>) wrote:
What do you mean by abuse scenarios? However, I would guess again that this is not a quic specific discussion and should probably rather happen in tsvwg which is the group that is maintain ECN in general.

Mirja

> Am 12.02.2018 um 16:42 schrieb Mikkel Fahnøe Jørgensen <[email-masked]<mailto:[email-masked]>>:
>
> On 12 February 2018 at 16.26.32, Mirja Kühlewind ([email-masked]<mailto:[email-masked]>) wrote:
>
>> Hi Ingemar,
>>
>> two points.
>>
>> > Am 09.02.2018 um 08:34 schrieb Ingemar Johansson S <[email-masked]<mailto:[email-masked]>>:
>> >
>> > Hi Eric, Koen + others
>> >
>> > From: De Schepper, Koen (Nokia - BE/Antwerp) [mailto:[email-masked]<mailto:[email-masked]>]
>> > To: [email-masked]<mailto:[email-masked]>; Ingemar Johansson S <[email-masked]<mailto:[email-masked]>>
>> > Cc: QUIC WG <[email-masked]<mailto:[email-masked]>>; Ian Swett <[email-masked]<mailto:[email-masked]>>; Lubashev, Igor <[email-masked]<mailto:[email-masked]>>; Christian Huitema <[email-masked]<mailto:[email-masked]>>
>> > From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>]
>> > www.ericsson.com<http://www.ericsson.com>
>> >
>> > You can't start a fire

---

From: Ingemar Johansson S <[email-masked]>
Date: Mon, 12 Feb 2018 21:11:56 +0000

Hi 

Please see inline

BR
Ingemar

> -----Original Message-----
> From: Mirja Kühlewind [mailto:[email-masked]]
> Sent: den 12 februari 2018 16:26
> Cc: De Schepper, Koen (Nokia - BE/Antwerp) <koen.de_schepper@nokia-
> bell-labs.com>; [email-masked]; Lubashev, Igor
> <[email-masked]>; Ian Swett <[email-masked]>; QUIC WG
> <[email-masked]>; Christian Huitema <[email-masked]>
> I think it would be good to be as explicit as possible here, therefore I would
> prefer if an endpoint that knows that it can not access the ECN IP bits
> indicates this directly in the handshake. In this case no further testing is
> needed.
<IJ> Yes, this was the original idea, we discussed this at the ECN QUIC side meeting though and afterwards and as far as I understand it, there was a consensus that it was unnecessarily complicated. So we selected a method where we just verify that the ECT(0),ECT(1),CE counters have reasonable values. If that is not the case, then it is an indication that either the path or the endpoints do not support ECN. </IJ>

> any protocol. Moreover, it’s more complicated than just testing ECT. I guess
> the general advice here is to remember which codepoints were send and
> point in time). However, how exactly this testing should look like, should not
> be specified in this doc (but more generally).
<IJ> It is possible that the actual path verification can be put as a separate document, not sure if that is accepted by the group or it is desired with a more elaborate description directly in the QUIC drafts. As regards to verification, I do believe that the proposed counters should be able to detect bleaching, accidental remarking from ECT(0) to ECT(1) and also cases where packets are not CE marked at all despite other signs of congestion </IJ>

> audience, does the presented text explain sufficiently enough how ECN
> works with connection migration ?
> > From: De Schepper, Koen (Nokia - BE/Antwerp)
> [mailto:[email-masked]]
> capability check fails. I assume this was not the intention, but if it is: First, we
> don’t have a protocol or decision point defined when that condition is met
> (sender should let the receiver know in the next packet), and second, I
> would always send the echo, as we might “try again later (with another
> ECT?)”, or might decide to use the ECN bits differently later.
> >
> > I also changed the text around the connection migration, I think before Eric
> reviewed it. I made it such that every new path creates a new connection
> state with an initialized congestion control state and ECN counters (at least
> ECN counters reset to 0s). Not sure if this matches with the other sections in
> the QUIC draft.
> >
> > I also had the thought whether it was really needed to have the 2 cases. I
> agree we should simplify, by just starting over and doing the check
> Lubashev, Igor <[email-masked]>; Christian Huitema
> <[email-masked]>; De Schepper, Koen (Nokia - BE/Antwerp)
> <[email-masked]>
> 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”.
> >
> > 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
> > 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
> > On Feb 1, 2018, at 3:07 AM, Ingemar Johansson S
> <[email-masked]> wrote:
> >
> > Hi
> > 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

---

From: Mirja Kühlewind <[email-masked]>
Date: Tue, 13 Feb 2018 13:29:29 +0100

Hi Ingemar,

see below.

> Am 12.02.2018 um 22:11 schrieb Ingemar Johansson S <[email-masked]>:
> 
> Hi 
> 
> Please see inline
> 
> BR
> Ingemar
> 

I checked the minutes and could not really find a conclusion there. I agree that there should be no negotiation in the handshake (both endpoint need to implement the ECN logic as part of v1) but what would be helpful is to let the other end know if you already know that you never will be able to provide feedback because you can just not read the bits in the IP header. That is not complicated at all.

I think what we need to specify in v1 is a way to provide ECN feedback (or indicate that this is not possible). However, we actually would not need to say anything about how ECN should be used. That’s a sender side decision. As long as you can get feedback, we are flexible in how to use and test ECN in v1 or anytime later. Of course it would be nice to provide some default recommendations with some easy fallback logic but that's the part we can experiment with and change any time without any need to change the protocol spec (as long as ECN feedback is provided, when ECN is used by the sender).

> <IJ> It is possible that the actual path verification can be put as a separate document, not sure if that is accepted by the group or it is desired with a more elaborate description directly in the…

We tried to design a more elaborated testing scheme where we would send 3 ECT0, the 3 ECT1, and the 3 CE (which we would of cause not count as a congestion indication as the CE was set by the sender). However, this was mostly to detect black-whaling which is probably less a concern than re-marking. I think today the most common case it that the bits will be set to zeros which is only a problem when there was some CE marking previously on the path that then would get lost. Thus in this case it would be recommend to not use ECN/not set packets as ECT at sender side.

However, as I said above, we probably should make recommendation how to use ECN by default but need to leave room for other usage/testing schemes. But after all the receiver being not able to read the bits and remarking on the path are to different things and should not be mixed up. If the sender can not read the bits this is know a priori and there is no ambiguity that needs to be tested. So why not signal it directly. The question if the sender can write ECN does not need to be communicated. There is no difference in the sender decided to not use ECN or it just can not use it; in both cases it is not necessary to send ECN feedback back. Only if a non-non-ECT is observed at the receiver, ECN feedback needs to be provided. However, knowing that the receiver can’t not provide feedback is important because in this case the sender MUST not set the packets as ECT as it will not be able to react to that signal. Testing the path in independent of that.

Mirja

>> <[email-masked]>

---

From: Ingemar Johansson S <[email-masked]>
Date: Wed, 14 Feb 2018 13:08:30 +0000

Hi

I attach the minutes from the side meeting in Singapore, I believe that they were only posted on the ecn-quic mailing list ☹ .

I agree that the sender/received issues are probably known a-priory and if a sender does know that its OS stack does not have the necessary API support for ECN then it does not make much sense to try it.

/Ingemar

> Sent: den 13 februari 2018 13:29
> >> I think it would be good to be as explicit as possible here,
> >> therefore I would prefer if an endpoint that knows that it can not
> >> access the ECN IP bits indicates this directly in the handshake. In
> >> this case no further testing is needed.
> > <IJ> Yes, this was the original idea, we discussed this at the ECN
> > QUIC side meeting though and afterwards and as far as I understand it,
> > there was a consensus that it was unnecessarily complicated. So we
> > selected a method where we just verify that the ECT(0),ECT(1),CE
> > counters have reasonable values. If that is not the case, then it is
> > an indication that either the path or the endpoints do not support
> > ECN. </IJ>
> 
> I checked the minutes and could not really find a conclusion there. I agree
> that there should be no negotiation in the handshake (both endpoint need
> to implement the ECN logic as part of v1) but what would be helpful is to let
> the other end know if you already know that you never will be able to
> provide feedback because you can just not read the bits in the IP header.
> That is not complicated at all.
> 
> I think what we need to specify in v1 is a way to provide ECN feedback (or
> indicate that this is not possible). However, we actually would not need to
> say anything about how ECN should be used. That’s a sender side decision.
> As long as you can get feedback, we are flexible in how to use and test ECN in
> v1 or anytime later. Of course it would be nice to provide some default
> recommendations with some easy fallback logic but that's the part we can
> experiment with and change any time without any need to change the
> protocol spec (as long as ECN feedback is provided, when ECN is used by the
> sender).
> 
> >
> >>
> >> Further, the path testing itself is independent of QUIC and can be
> >> used for any protocol. Moreover, it’s more complicated than just
> >> testing ECT. I guess the general advice here is to remember which
> >> codepoints were send and compare this to the feedback provided. If
> >> discrepancies are observed that indicate that a middlebox has changed
> >> these bits, all packets should be marked as no-ECT (while additional
> >> testing MAY be performed at any later point in time). However, how
> >> exactly this testing should look like, should not be specified in this doc
> (but more generally).
> > <IJ> It is possible that the actual path verification can be put as a
> > separate document, not sure if that is accepted by the group or it is
> > desired with a more elaborate description directly in the QUIC drafts.
> > As regards to verification, I do believe that the proposed counters
> > should be able to detect bleaching, accidental remarking from ECT(0)
> > to ECT(1) and also cases where packets are not CE marked at all
> > despite other signs of congestion </IJ>
> 
> We tried to design a more elaborated testing scheme where we would send
> 3 ECT0, the 3 ECT1, and the 3 CE (which we would of cause not count as a
> congestion indication as the CE was set by the sender). However, this was
> mostly to detect black-whaling which is probably less a concern than re-
> marking. I think today the most common case it that the bits will be set to
> zeros which is only a problem when there was some CE marking previously
> on the path that then would get lost. Thus in this case it would be
> recommend to not use ECN/not set packets as ECT at sender side.
> 
> However, as I said above, we probably should make recommendation how to
> use ECN by default but need to leave room for other usage/testing schemes.
> But after all the receiver being not able to read the bits and remarking on the
> path are to different things and should not be mixed up. If the sender can
> not read the bits this is know a priori and there is no ambiguity that needs to
> be tested. So why not signal it directly. The question if the sender can write
> ECN does not need to be communicated. There is no difference in the
> sender decided to not use ECN or it just can not use it; in both cases it is not
> necessary to send ECN feedback back. Only if a non-non-ECT is observed at
> the receiver, ECN feedback needs to be provided. However, knowing that
> the receiver can’t not provide feedback is important because in this case the
> sender MUST not set the packets as ECT as it will not be able to react to that
> signal. Testing the path in independent of that.
> 
> Mirja
> 
> 
> >
> >
> >>
> >> Mirja
> >>
> >>
> >> capability check fails. I assume this was not the intention, but if
> >> it is: First, we don’t have a protocol or decision point defined when
> >> that condition is met (sender should let the receiver know in the
> >> next packet), and second, I would always send the echo, as we might
> >> “try again later (with another ECT?)”, or might decide to use the ECN bits
> differently later.
> >>>
> >>> before Eric
> >> reviewed it. I made it such that every new path creates a new
> >> counters (at least ECN counters reset to 0s). Not sure if this
> >> matches with the other sections in the QUIC draft.
> >>>
> >>> cases. I
> >>> the
> >> same process of: (a) verify ECN capability and if successful to
> >> 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”.
> >>>
> >> 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.
> >>>
> >> 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.
> >>>
> >>> 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
> >> 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
> >>>
> >>>
> >>>
> >>>
> >>> I have written up different aspects of connection migration and how
> >>> it
> >> plays with ECN.
> .
> >> 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
> >>>                 You can't start a fire  Worrying 'bout your little
> >>> world falling apart
> >>>               Bruce Springsteen

---

From: "De Schepper, Koen (Nokia - BE/Antwerp)" <[email-masked]>
Date: Wed, 14 Feb 2018 16:48:48 +0000

Hi Mirja,

Why would you like to see the distinction?

It was indeed decided in the side meeting that we should not foresee extra protocol complexity for signalling that the receiver cannot read the ecn bits.

For me the reasons were: It is not a desired situation which will hopefully disappear in the future, and I don't think it is so useful for a sender to know. We now assume reading 00 bits and echo all counters unincremented with 0 values in that case, just as if the path bleaches it. If we make an explicit protocol exchange for it, it feels like it is an extra feature ;-). Also people might start making their congestion control more complex with up to 2 more conditional parameters (sender-cannot-set-ecn and receiver-cannot-read-ecn booleans, next to no-ecn). Not to mention extra interop testcases with such sender's/receiver's extra functionality.

To make your code simple and platform independent, not being able to set/read echo bits should be invisible until the point of the missing socket API call, which will most probably have conditional compiler directives per platform at that point.

So conclusion was: Any higher layer protocol code should not make any distinction between host inability and path bleaching, and we only have functionality for general "end2end ecn inability".

Agreed that the receiver code should be independent from how ecn is used. This is the case now. For the receiver we only increment and echo the counters all the time. That's it, very simple. Only the sender determines how ecn capability is checked and how ecn is used.

Maybe also a good point that the current capability check is the minimal?? And needs some extra checks?

Regards,
Koen.

Outlook voor Android<https://aka.ms/ghei36> downloaden

________________________________
From: Ingemar Johansson S <[email-masked]>
Sent: Wednesday, February 14, 2018 2:08:30 PM
To: Mirja Kühlewind
Cc: De Schepper, Koen (Nokia - BE/Antwerp); [email-masked]; Lubashev, Igor; Ian Swett; QUIC WG; Christian Huitema; Ingemar Johansson S
Subject: RE: ECN in QUIC connection migration

Hi

/Ingemar

---

From: Ingemar Johansson S <[email-masked]>
Date: Wed, 21 Feb 2018 14:37:40 +0000

Hi

Trying to pick up this thread again.

Do we have some kind of minimal consensus around the proposed ECN functionality in QUIC ?
https://github.com/quicwg/base-drafts/wiki/ECN-in-QUIC#suggested-additions-to-to-become-rfcs

/Ingemar

From: De Schepper, Koen (Nokia - BE/Antwerp) [mailto:[email-masked]]
Sent: den 14 februari 2018 17:49
To: Mirja Kühlewind <[email-masked]>; Ingemar Johansson S <[email-masked]>
Cc: [email-masked]; Lubashev, Igor <[email-masked]>; Ian Swett <[email-masked]>; QUIC WG <[email-masked]>; Christian Huitema <[email-masked]>; Ingemar Johansson S <[email-masked]>
Subject: RE: ECN in QUIC connection migration

Hi Mirja,

________________________________
From: Ingemar Johansson S <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, February 14, 2018 2:08:30 PM
To: Mirja Kühlewind
Cc: De Schepper, Koen (Nokia - BE/Antwerp); [email-masked]<mailto:[email-masked]>; Lubashev, Igor; Ian Swett; QUIC WG; Christian Huitema; Ingemar Johansson S
Subject: RE: ECN in QUIC connection migration

Hi

/Ingemar

> Cc: De Schepper, Koen (Nokia - BE/Antwerp) <koen.de_schepper@nokia-
<mailto:koen.de_schepper@nokia-%0b>> bell-labs.com>; [email-masked]<mailto:[email-masked]>; Lubashev, Igor
> <[email-masked]<mailto:[email-masked]>>; Ian Swett <[email-masked]<mailto:[email-masked]>>; QUIC WG
> <[email-masked]<mailto:[email-masked]>>; Christian Huitema <[email-masked]<mailto:[email-masked]>>
> > Am 12.02.2018 um 22:11 schrieb Ingemar Johansson S
> <[email-masked]<mailto:[email-masked]>>:
> >
> > Hi
> >
> > Please see inline
> >
> > BR
> > Ingemar
> >
<mailto:koen.de_schepper@nokia-%0b>> >> bell-labs.com>; [email-masked]<mailto:[email-masked]>; Lubashev, Igor
> >> <[email-masked]<mailto:[email-masked]>>; Ian Swett <[email-masked]<mailto:[email-masked]>>; QUIC WG
> >> <[email-masked]<mailto:[email-masked]>>; Christian Huitema <[email-masked]<mailto:[email-masked]>>
> >>> Am 09.02.2018 um 08:34 schrieb Ingemar Johansson S
> >> <[email-masked]<mailto:[email-masked]>>:
> >>>
> >>> Hi Eric, Koen + others
> >>>
> >>> To: [email-masked]<mailto:[email-masked]>; Ingemar Johansson S
> >> <[email-masked]<mailto:[email-masked]>>
> >>> Cc: QUIC WG <[email-masked]<mailto:[email-masked]>>; Ian Swett <[email-masked]<mailto:[email-masked]>>;
> >> Lubashev, Igor <[email-masked]<mailto:[email-masked]>>; Christian Huitema
> >> <[email-masked]<mailto:[email-masked]>>
> >>> Cc: QUIC WG <[email-masked]<mailto:[email-masked]>>; Ian Swett <[email-masked]<mailto:[email-masked]>>;
> >> Lubashev, Igor <[email-masked]<mailto:[email-masked]>>; Christian Huitema
> >> <[email-masked]<mailto:[email-masked]>>; De Schepper, Koen (Nokia - BE/Antwerp)
> >> <[email-masked]<mailto:[email-masked]>>
> >> <[email-masked]<mailto:[email-masked]>> wrote:
> >>>
> >>> Hi

---

From: Gorry Fairhurst <[email-masked]>
Date: Wed, 21 Feb 2018 16:57:36 +0000

So I worked carefully through the text. Most of what I saw looked sound 
- well done!

At places the language looked inconsistent with either other parts of 
the document or with other RFCs. I updated the wiki to resulve thses 
issues. Hoepfully the new text is more close to what we need,

Gorry

On 21/02/2018, 14:37, Ingemar Johansson S wrote:
> *From:* De Schepper, Koen (Nokia - BE/Antwerp) 
> *Sent:* den 14 februari 2018 17:49
> *To:* Mirja Kühlewind <[email-masked]>; Ingemar 
> Johansson S <[email-masked]>
> *Cc:* [email-masked]; Lubashev, Igor <[email-masked]>; Ian 
> Swett <[email-masked]>; QUIC WG <[email-masked]>; Christian 
> Huitema <[email-masked]>; Ingemar Johansson S 
> <[email-masked]>
> *Subject:* RE: ECN in QUIC connection migration
>
> Hi Mirja,
>
> It was indeed decided in the side meeting that we should not foresee 
> extra protocol complexity for signalling that the receiver cannot read 
> the ecn bits.
>
> For me the reasons were: It is not a desired situation which will 
> hopefully disappear in the future, and I don't think it is so useful 
> for a sender to know. We now assume reading 00 bits and echo all 
> counters unincremented with 0 values in that case, just as if the path 
> bleaches it. If we make an explicit protocol exchange for it, it feels 
> like it is an extra feature ;-). Also people might start making their 
> congestion control more complex with up to 2 more conditional 
> parameters (sender-cannot-set-ecn and receiver-cannot-read-ecn 
> booleans, next to no-ecn). Not to mention extra interop testcases with 
> such sender's/receiver's extra functionality.
>
> To make your code simple and platform independent, not being able to 
> set/read echo bits should be invisible until the point of the missing 
> socket API call, which will most probably have conditional compiler 
> directives per platform at that point.
>
> So conclusion was: Any higher layer protocol code should not make any 
> distinction between host inability and path bleaching, and we only 
> have functionality for general "end2end ecn inability".
>
> Agreed that the receiver code should be independent from how ecn is 
> used. This is the case now. For the receiver we only increment and 
> echo the counters all the time. That's it, very simple. Only the 
> sender determines how ecn capability is checked and how ecn is used.
>
> Outlook voor Android <https://aka.ms/ghei36> downloaden
>
> ------------------------------------------------------------------------
>
> *From:*Ingemar Johansson S <[email-masked] 
> <mailto:[email-masked]>>
> *Sent:* Wednesday, February 14, 2018 2:08:30 PM
> *To:* Mirja Kühlewind
> *Cc:* De Schepper, Koen (Nokia - BE/Antwerp); [email-masked] 
> <mailto:[email-masked]>; Lubashev, Igor; Ian Swett; QUIC WG; 
> Christian Huitema; Ingemar Johansson S
> *Subject:* RE: ECN in QUIC connection migration
>
> Hi
>
> I attach the minutes from the side meeting in Singapore, I believe 
> that they were only posted on the ecn-quic mailing list ☹ .
>
> I agree that the sender/received issues are probably known a-priory 
> and if a sender does know that its OS stack does not have the 
> necessary API support for ECN then it does not make much sense to try it.
>
> /Ingemar
>
>
> > To: Ingemar Johansson S <[email-masked] 
> <mailto:[email-masked]>>
> <mailto:koen.de_schepper@nokia-%0b>> bell-labs.com>; 
> [email-masked] <mailto:[email-masked]>; Lubashev, Igor
> > <[email-masked] <mailto:[email-masked]>>; Ian Swett 
> <[email-masked] <mailto:[email-masked]>>; QUIC WG
> > <[email-masked] <mailto:[email-masked]>>; Christian Huitema 
> <[email-masked] <mailto:[email-masked]>>
> > <[email-masked] 
> <mailto:[email-masked]>>:
> > >
> > > Hi
> > >
> > > Please see inline
> > >
> > > BR
> > > Ingemar
> > >
> > >> To: Ingemar Johansson S <[email-masked] 
> <mailto:[email-masked]>>
> <mailto:koen.de_schepper@nokia-%0b>> >> bell-labs.com>; 
> [email-masked] <mailto:[email-masked]>; Lubashev, Igor
> > >> <[email-masked] <mailto:[email-masked]>>; Ian Swett 
> <[email-masked] <mailto:[email-masked]>>; QUIC WG
> > >> <[email-masked] <mailto:[email-masked]>>; Christian Huitema 
> <[email-masked] <mailto:[email-masked]>>
> > >> <[email-masked] 
> <mailto:[email-masked]>>:
> > >>>
> > >>> Hi Eric, Koen + others
> > >>>
> > >>> To: [email-masked] <mailto:[email-masked]>; Ingemar 
> Johansson S
> > >> <[email-masked] 
> <mailto:[email-masked]>>
> > >>> Cc: QUIC WG <[email-masked] <mailto:[email-masked]>>; Ian Swett 
> <[email-masked] <mailto:[email-masked]>>;
> > >> Lubashev, Igor <[email-masked] 
> <mailto:[email-masked]>>; Christian Huitema
> > >> <[email-masked] <mailto:[email-masked]>>
> > >>> From: [email-masked] <mailto:[email-masked]> 
> [mailto:[email-masked]]
> > >>> To: Ingemar Johansson S <[email-masked] 
> <mailto:[email-masked]>>
> > >>> Cc: QUIC WG <[email-masked] <mailto:[email-masked]>>; Ian Swett 
> <[email-masked] <mailto:[email-masked]>>;
> > >> Lubashev, Igor <[email-masked] 
> <mailto:[email-masked]>>; Christian Huitema
> > >> <[email-masked] <mailto:[email-masked]>>; De Schepper, 
> Koen (Nokia - BE/Antwerp)
> > >> <[email-masked] 
> <mailto:[email-masked]>>
> > >> <[email-masked] 
> <mailto:[email-masked]>> wrote:
> > >>>
> > >>> Hi
> migration
> <mailto:[email-masked]>
> > >>> www.ericsson.com <http://www.ericsson.com>
> > >>>

---

From: Ingemar Johansson S <[email-masked]>
Date: Sun, 25 Feb 2018 18:08:26 +0000

Thank for the review. There are still a few matters that are unclear in the text, these are highlighted with [ED note....]. But I do believe that the proposed text is a good first start and should be possible to pull request into the relevant drafts in a not too distant future.

/Ingemar

> From: Gorry Fairhurst [mailto:[email-masked]]
> Sent: den 21 februari 2018 17:58
> bell-labs.com>; Mirja Kühlewind <[email-masked]>; QUIC
> WG <[email-masked]>; Christian Huitema <[email-masked]>; Ian Swett
> <[email-masked]>; Lubashev, Igor <[email-masked]>;
> [email-masked]
> At places the language looked inconsistent with either other parts of the
> document or with other RFCs. I updated the wiki to resulve thses issues.
> Hoepfully the new text is more close to what we need,
> 
> Gorry
> 
> > https://github.com/quicwg/base-drafts/wiki/ECN-in-QUIC#suggested-
> addit
> > ions-to-to-become-rfcs
> >
> > /Ingemar
> >
> > > >> therefore I would prefer if an endpoint that knows that it can
> > > >> not access the ECN IP bits indicates this directly in the
> > > >> handshake. In this case no further testing is needed.
> > > > QUIC side meeting though and afterwards and as far as I understand
> > > > it, there was a consensus that it was unnecessarily complicated.
> > > > So we selected a method where we just verify that the
> > > > ECT(0),ECT(1),CE counters have reasonable values. If that is not
> > > > the case, then it is an indication that either the path or the
> > > > endpoints do not support ECN. </IJ>
> > >
> > > that there should be no negotiation in the handshake (both endpoint
> > > need to implement the ECN logic as part of v1) but what would be
> > > helpful
> > is to let
> > > the other end know if you already know that you never will be able
> > > to provide feedback because you can just not read the bits in the IP
> > header.
> > > v1 or anytime later. Of course it would be nice to provide some
> > > default recommendations with some easy fallback logic but that's the
> > > part we can experiment with and change any time without any need to
> > > change the protocol spec (as long as ECN feedback is provided, when
> > > ECN is used
> > by the
> > > sender).
> > >
> > > >
> > > >>
> > > >> Further, the path testing itself is independent of QUIC and can
> > > >> be used for any protocol. Moreover, it’s more complicated than
> > > >> just testing ECT. I guess the general advice here is to remember
> > > >> which codepoints were send and compare this to the feedback
> > > >> provided. If discrepancies are observed that indicate that a
> > > >> middlebox has changed these bits, all packets should be marked as
> > > >> no-ECT (while additional testing MAY be performed at any later
> > > >> point in time). However, how exactly this testing should look
> > > >> like, should not be specified in
> > this doc
> > > (but more generally).
> > > > <IJ> It is possible that the actual path verification can be put
> > > > as a separate document, not sure if that is accepted by the group
> > > > or it is desired with a more elaborate description directly in the QUIC
> drafts.
> > > > As regards to verification, I do believe that the proposed
> > > > counters should be able to detect bleaching, accidental remarking
> > > > from ECT(0) to ECT(1) and also cases where packets are not CE
> > > > marked at all despite other signs of congestion </IJ>
> > >
> > > 3 ECT0, the 3 ECT1, and the 3 CE (which we would of cause not count
> > > as a congestion indication as the CE was set by the sender).
> > > However,
> > this was
> > > mostly to detect black-whaling which is probably less a concern than
> > > re- marking. I think today the most common case it that the bits
> > > will be
> > set to
> > > zeros which is only a problem when there was some CE marking
> > > previously on the path that then would get lost. Thus in this case
> > > it would be recommend to not use ECN/not set packets as ECT at sender
> side.
> > >
> > > However, as I said above, we probably should make recommendation
> how
> > > to use ECN by default but need to leave room for other usage/testing
> > schemes.
> > > the receiver, ECN feedback needs to be provided. However, knowing
> > > that the receiver can’t not provide feedback is important because in
> > > this
> > case the
> > > >> audience, does the presented text explain sufficiently enough how
> > > >> ECN works with connection migration ?
> > > >>> https://github.com/quicwg/base-drafts/wiki/ECN-in-QUIC#transport
> > > >>> -
> > > >> draft-connection-migration
> > > >>>
> > > >>>
> > > >>> /Ingemar
> > > >>>
> > > >>>
> > > >> capability check fails. I assume this was not the intention, but
> > > >> if it is: First, we don’t have a protocol or decision point
> > > >> defined when that condition is met (sender should let the
> > > >> receiver know in the next packet), and second, I would always
> > > >> send the echo, as we might “try again later (with another ECT?)”,
> > > >> or might decide to use the
> > ECN bits
> > > differently later.
> > > >>>
> > > >> connection state with an initialized congestion control state and
> > > >> ECN counters (at least ECN counters reset to 0s). Not sure if
> > > >> this matches with the other sections in the QUIC draft.
> > > >>>
> > > >> agree we should simplify, by just starting over and doing the
> > > >> 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”.
> > > >>>
> > > >> 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.
> > > >>>
> > > >> 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.
> > > >>>
> > > >> 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.
> > > >>>
> > > >>> 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
> > > >>>
> > > >> 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
> > > >>>
> > > >>> Network Protocols & E2E Performance Labratoriegränd 11
> > > >>> 971 28, Luleå, Sweden
> > > >>> Phone +46-1071 43042
> > > >>> SMS/MMS +46-73 078 3289
> > > >>>                 You can't start a fire  Worrying 'bout your
> > > >>> little world falling apart
> > > >>>               Bruce Springsteen