Hi Lars,
Lars Eggert <l...@eggert.org> writes:
On 2022-8-23, at 18:57, Christian Hopps <cho...@chopps.org> wrote:
### 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.
ESP in TCP meant as a fall-back, "use only if you have to", solution for IPsec.
It say so right in the abstract for RFC8229.
The reason we had an early transport area review was to avoid any last minute
surprises and their expert review should be good enough at this late date.
Thanks,
Chris.
https://datatracker.ietf.org/doc/review-ietf-ipsecme-iptfs-12-tsvart-early-touch-2021-12-07/
https://datatracker.ietf.org/doc/review-ietf-ipsecme-iptfs-03-tsvart-early-touch-2020-12-03/
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?
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
