RE: ECN in QUIC connection migration

[Ingemar Johansson S <[e-mail]>]

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

> -----Original Message-----
> From: Gorry Fairhurst [mailto:[e-mail]]
> Sent: den 21 februari 2018 17:58
> To: Ingemar Johansson S <[e-mail]>
> Cc: De Schepper, Koen (Nokia - BE/Antwerp) <koen.de_schepper@nokia-
> bell-labs.com>; Mirja Kühlewind <[e-mail]>; QUIC
> WG <[e-mail]>; Christian Huitema <[e-mail]>; Ian Swett
> <[e-mail]>; Lubashev, Igor <[e-mail]>;
> [e-mail]
> Subject: Re: ECN in QUIC connection migration
> 
> 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:
> >
> > 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-
> addit
> > ions-to-to-become-rfcs
> >
> > /Ingemar
> >
> > *From:* De Schepper, Koen (Nokia - BE/Antwerp)
> > [mailto:[e-mail]]
> > *Sent:* den 14 februari 2018 17:49
> > *To:* Mirja Kühlewind <[e-mail]>; Ingemar
> > Johansson S <[e-mail]>
> > *Cc:* [e-mail]; Lubashev, Igor <[e-mail]>; Ian
> > Swett <[e-mail]>; QUIC WG <[e-mail]>; Christian
> > Huitema <[e-mail]>; Ingemar Johansson S
> > <[e-mail]>
> > *Subject:* RE: ECN in QUIC connection migration
> >
> > 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 <[e-mail]
> > <mailto:[e-mail]>>
> > *Sent:* Wednesday, February 14, 2018 2:08:30 PM
> > *To:* Mirja Kühlewind
> > *Cc:* De Schepper, Koen (Nokia - BE/Antwerp); [e-mail]
> > <mailto:[e-mail]>; 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
> >
> >
> > > -----Original Message-----
> > > From: Mirja Kühlewind [mailto:[e-mail]]
> > > Sent: den 13 februari 2018 13:29
> > > To: Ingemar Johansson S <[e-mail]
> > <mailto:[e-mail]>>
> > > Cc: De Schepper, Koen (Nokia - BE/Antwerp)
> <koen.de_schepper@nokia-
> > <mailto:koen.de_schepper@nokia-%0b>> bell-labs.com>;
> > [e-mail] <mailto:[e-mail]>; Lubashev, Igor
> > > <[e-mail] <mailto:[e-mail]>>; Ian Swett
> > <[e-mail] <mailto:[e-mail]>>; QUIC WG
> > > <[e-mail] <mailto:[e-mail]>>; Christian Huitema
> > <[e-mail] <mailto:[e-mail]>>
> > > Subject: Re: ECN in QUIC connection migration
> > >
> > > Hi Ingemar,
> > >
> > > see below.
> > >
> > > > Am 12.02.2018 um 22:11 schrieb Ingemar Johansson S
> > > <[e-mail]
> > <mailto:[e-mail]>>:
> > > >
> > > > Hi
> > > >
> > > > Please see inline
> > > >
> > > > BR
> > > > Ingemar
> > > >
> > > >> -----Original Message-----
> > > >> From: Mirja Kühlewind [mailto:[e-mail]]
> > > >> Sent: den 12 februari 2018 16:26
> > > >> To: Ingemar Johansson S <[e-mail]
> > <mailto:[e-mail]>>
> > > >> Cc: De Schepper, Koen (Nokia - BE/Antwerp)
> > > >> <koen.de_schepper@nokia-
> > <mailto:koen.de_schepper@nokia-%0b>> >> bell-labs.com>;
> > [e-mail] <mailto:[e-mail]>; Lubashev, Igor
> > > >> <[e-mail] <mailto:[e-mail]>>; Ian Swett
> > <[e-mail] <mailto:[e-mail]>>; QUIC WG
> > > >> <[e-mail] <mailto:[e-mail]>>; Christian Huitema
> > <[e-mail] <mailto:[e-mail]>>
> > > >> Subject: Re: ECN in QUIC connection migration
> > > >>
> > > >> 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.
> > > > <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
> > > >>
> > > >>
> > > >>> Am 09.02.2018 um 08:34 schrieb Ingemar Johansson S
> > > >> <[e-mail]
> > <mailto:[e-mail]>>:
> > > >>>
> > > >>> 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:[e-mail]]
> > > >>> Sent: den 2 februari 2018 15:44
> > > >>> To: [e-mail] <mailto:[e-mail]>; Ingemar
> > Johansson S
> > > >> <[e-mail]
> > <mailto:[e-mail]>>
> > > >>> Cc: QUIC WG <[e-mail] <mailto:[e-mail]>>; Ian Swett
> > <[e-mail] <mailto:[e-mail]>>;
> > > >> Lubashev, Igor <[e-mail]
> > <mailto:[e-mail]>>; Christian Huitema
> > > >> <[e-mail] <mailto:[e-mail]>>
> > > >>> Subject: RE: ECN in QUIC connection migration
> > > >>>
> > > >>> 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.
> > > >>>
> > > >>> From: [e-mail] <mailto:[e-mail]>
> > [mailto:[e-mail]]
> > > >>> Sent: Friday, February 2, 2018 12:02 AM
> > > >>> To: Ingemar Johansson S <[e-mail]
> > <mailto:[e-mail]>>
> > > >>> Cc: QUIC WG <[e-mail] <mailto:[e-mail]>>; Ian Swett
> > <[e-mail] <mailto:[e-mail]>>;
> > > >> Lubashev, Igor <[e-mail]
> > <mailto:[e-mail]>>; Christian Huitema
> > > >> <[e-mail] <mailto:[e-mail]>>; De
> Schepper,
> > Koen (Nokia - BE/Antwerp)
> > > >> <[e-mail]
> > <mailto:[e-mail]>>
> > > >>> Subject: Re: ECN in QUIC connection migration
> > > >>>
> > > >>> 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]
> > <mailto:[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
> > > >>>
> > > >>> 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 <http://www.ericsson.com>
> > > >>>
> > > >>>                 You can't start a fire  Worrying 'bout your
> > > >>> little world falling apart
> > > >>>               Bruce Springsteen
> > > >>> ==================================
> > > >
> >