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.
signature.asc
Description: PGP signature
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
