RE: ECN in QUIC connection migration

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

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