Hi Christian, On 2022-8-23, at 18:57, Christian Hopps <cho...@chopps.org> wrote: >> ### Section 2.4.1, paragraph 3 >> ``` >> For similar reasons as given in [RFC7510] the non-congestion- >> controlled mode should only be used where the user has full >> administrative control over the path the tunnel will take. This is >> required so the user can guarantee the bandwidth and also be sure as >> to not be negatively affecting network congestion [RFC2914]. In this >> case, packet loss should be reported to the administrator (e.g., via >> syslog, YANG notification, SNMP traps, etc.) so that any failures due >> to a lack of bandwidth can be corrected. >> ``` >> There is a lot more nuance and there are a lot more restrictions in RFC7510 >> that >> also apply here. If a non-congestion-controlled mode is desired, especially >> without even using RFC8084 circuit breakers, similar mandatory text needs to >> be >> crafted for this mechanism. (I would also strongly suggest to require circuit >> breakers here.) > > There are in fact operators that know what they are doing and do not want > circuit breaker to kick in. We can RECOMMEND, but not require.
I'm fine with recommending RFC8040 CBs. It would be helpful if the document specified how to implement them, i.e., if they are supposed to be a separate standalone deployment or operate in-band based on AGGFRAG_PAYLOAD data. (I'd assume that even "operators that know what they are doing" would be interested in protecting their network from misconfigurations and/or buggy implementations.) > ### Section 2.4.2, paragraph 0 >> ``` >> 2.4.2. Congestion-Controlled Mode >> ``` >> This mode adds a LOT of complexity to this mechanism. Is this really needed? >> Could not RFC8229 be used instead of defining an entirely separate congestion >> control scheme for (padded/fragmented) ESP? > > We cannot use TCP, the entire point of this work is to fully decouple the > sending packet rate (outer packets) from the users offered load (inner > packets). Using TCP removes this control and so it is a non-starter. That is not obviously true. The tunnel implementation controls the timing of when inner packets are sent over the TCP connection, just as it is able to add padding. In terms of performance, TCP inside TFRC can have somewhat better performance, because TFRC doesn't impose reliablity/ordering as an outer TCP connection would, but there are still two CCs fighting it out in terms of send rate calculation. It's not immediately clear that the specification overhead of using TFRC is worth it in terms of performance. Are there measurements? >> ### Section 2.4.2.1, paragraph 1 >> ``` >> In additional to congestion control, implementations MAY choose to >> define and implement circuit breakers [RFC8084] as a recovery method >> of last resort. Enabling circuit breakers is also a reason a user >> may wish to enable congestion information reports even when using the >> non-congestion-controlled mode of operation. >> ``` >> This makes no sense. If implemented in addition to CC, circuit breakers will >> never fire, because a functioning congestion control algorithm will always >> maintain a send rate below the circuit breaker threshold. > > This text is talking to implementations not users. It's suggesting > implementations *also* offer circuit breaker functionality. > >> What would make sense is to use circuit breakers in the >> non-congestion-controlled case, to provide a safety mechanism in cases the >> network provisioning changes for an active tunnel. > > This is in fact the idea. Perhaps we should state this more clearly? You are right, I misunderstood this paragraph. It would be useful to clarify that for CBR mode, CBs are recommended and if so, CC information needs to be enabled to give the CB information to act on (also see my previous comment about specifying how CBs work here, i.e., based on AGGFRAG_PAYLOAD CC information.) >> ### 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.) >> ### Section 6.1.2, paragraph 9 >> ``` >> RTT: >> A 22-bit value specifying the sender's current round-trip time >> estimate in microseconds. The value MAY be zero prior to the >> sender having calculated a round-trip time estimate. The value >> SHOULD be set to zero on non-AGGFRAG_PAYLOAD-enabled SAs. If the >> RTT is equal to or larger than 0x3FFFFF the value MUST be set to >> 0x3FFFFF. >> ``` >> This can only encode RTTs of up to around four seconds. That is too little >> for >> Internet usage. (Same concern about other 22-bit microsecond values below.) > > We deal with that by indicating the RTT is *at least* 4 seconds. Remember > that we are implementing a fixed-rate tunnel here. If the RTT is at least 4 > seconds it's going to basically slow the tunnel to a standstill and so is way > more than enough fidelity. The RTT goes into the rate calculation, and a capped RTT leads to a rate that may be low but still higher than what TFRC would calculate with a non-capped RTT. Given that TFRC is a pretty coarse algorithm, using usec resolution is probably overkill anyway. Would going to msec resolution work? Thanks, Lars
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
