Re: ECN in QUIC connection migration

[Gorry Fairhurst <[e-mail]>]

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-additions-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
> > >>> ==================================
> > >
>