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