If it were me, I might add "unless all inner packets have the same marking", but I won't die on that hill.
On Thu, Aug 25, 2022 at 10:57 AM Christian Hopps <cho...@chopps.org> wrote: > > Martin Duke <martin.h.d...@gmail.com> writes: > > > I'm not sure we've landed on a good solution with the ECN text. Two > > weeks ago I pushed Christian to do something more sophisticated with > > ECN, but realized that this is such a complicated subject that I > > wrote a draft (which, to my knowledge, no one has read): > > > > https://datatracker.ietf.org/doc/ > > draft-duke-tsvwg-ecn-aggregating-tunnels/ > > > > I am not sure what this means: > > > > "the ECN value from a congestion indicating packet should be the > > source of the copied value." > > > > So if an ECT(0) and a CE packet are in the same outer packet, the > > outer packet should be CE? But what if the inner CE packet was > > originally ECT(1) and this is an indication of minor congestion? Then > > the ECT(0) will be marked CE on egress and execute a loss response, > > which is inappropriate, even if there is no congestion whatsoever on > > the tunnel path. > > > > Or is the copied value on tunnel egress? Both? > > > > The old language, IIRC, was just to make the outer packet Not-ECT. > > This doesn't send spurious signals to the endpoints, and the only > > drawback is that the tunnel has to do a packet drop instead of using > > an ECN mark. As CBR is the preferred mode of operation here, it seems > > like this is a small price to pay. To summarize: > > > > 1) If my draft were even half-baked, it would be the best advice to > > include > > 2) Since it is not baked, I think Not-ECT (6040 "compatibility mode") > > is the best advice > > 3) The current text, IMO, is a bit ambigous, and will result in > > pathological behavior. > > I agree that compatibility mode is thing to do here, and here is the new > text: > > [[RFC3168]] and [[RFC4301]], updated by [[RFC6040]] defines behaviors > for marking > the outer ECN field value based on the ECN field of the inner packet. > As AGGFRAG mode may have multiple inner packets present in a single > outer packet, and there is no obvious correct way to map these > multiple values to the single outer packet ECN field value, the > tunnel ingress endpoint SHOULD operate in the "compatibility" mode > rather than the "default" mode from RFC6040. In particular this means > that the ingress (sending) endpoint of the tunnel always sets the > newly constructed outer encapsulating packet header ECN field > to Not-ECT [[RFC6040]]. > > We have a couple more ADs with ECN as a DISCUSS: > > - Lars - You wanted us to be explicit about what to do with ECN field > based on RFC6040. The propsed text above satisfies this requirement I > beleive. Agreed? > > - Zaheduzzaman - You added a +1 to Lars' DISCUSS for ECN. Would you also > be satisfied with the above text? > > Thanks, > Chris. > > > Martin > > > > On Wed, Aug 24, 2022 at 5:46 AM Christian Hopps <cho...@chopps.org> > > wrote: > > > > > > Christian Hopps <cho...@chopps.org> writes: > > > > >> On Aug 24, 2022, at 04:28, Lars Eggert <l...@eggert.org> > > wrote: > > >> > > >>>> ### Section 3.1, paragraph 0 > > >>>> ``` > > >>>> 3.1. ECN Support > > >>>> ``` > > >>>> There is a lot more nuance to this, as described in RC6040. > > This document needs > > >>>> to follow that existing standard rather than define another > > variant. > > >>> > > >>> We reference RFC3168 which talks directly to handling ECN > > with IPsec security associations. We are not defining a new > > variant. I see that RFC6040 updates the RFCs we reference so we > > perhaps should add that reference here as well? > > >> > > >> It's not just adding the reference. RFC6040 specifies how ECN > > applies to tunnels, including this tunnel, so it needs to be > > followed here (or there needs to be a solid rationale/discussion > > about which aspects are not being followed and why.) > > > > > > I've changed the ECN section text on marking to: > > > > [slight grammar fix] > > > > [[RFC3168]] and [[RFC4301]] define behaviors for marking ECN > > based on the > > ingress and egress of the inner packet. These RFCs were later > > updated > > by [[RFC6040]]. The methods defined in [[RFC6040]] SHOULD be > > followed with > > the addition that if multiple inner packets are being > > encapsulated in > > an AGGFRAG mode outer packet, the ECN value from a congestion > > indicating packet should be the source of the copied value. > > > > Thanks, > > Chris. > >
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
