Hi Martin,
please see inline. On Mon, Aug 8, 2022 at 5:12 AM Valery Smyslov < <mailto:s...@elvis.ru> s...@elvis.ru> wrote: > > (Sec 9.1) > "TCP-in-TCP can also lead to "TCP meltdown", where stacked instances > of TCP can result in significant impacts to performance > [TCP-MELTDOWN]. For the case in this document, such meltdown can > occur when the window size of the outer TCP connection is smaller > than the window sizes of the inner TCP connections. The resulting > interactions can lead to packets backing up in the outer TCP > connection's send buffers. In order to limit this effect, the outer > TCP connection should have limits on its send buffer size and on the > rate at which it reduces its window size." > > Which "window" are you referring to? Receive window, congestion window, > or the > send buffer? My reading of [TCP-MELTDOWN] is that the tunnel ingress > should set > its send buffer size to the BDP of the tunnel, which is easier said than done. > It appears you are using "window" and "send buffer" interchangeably here in a > way that is confusing. This text was suggested by Joe Touch (https://mailarchive.ietf.org/arch/msg/ipsec/eD85hixrzfqwg4UhwRZ8WL5PkDA/) If you think it is unclear, can you please suggest how it can be improved? OK, I'll start a separate thread with Joe and you. OK, thank you. > (9.5) > Implementations SHOULD follow the ECN compatibility mode for tunnel > ingress as described in [RFC6040]. In compatibility mode, the outer > tunnel TCP connection marks its packet headers as not ECN-capable. > If upon egress, the arriving outer header is marked with CE, the > implementation will drop the inner packet, since there is not a > distinct inner packet header onto which to translate the ECN > markings. > > This is not an accurate summary of compatibility mode. In compatibility mode, > the outer packet is marked Not-ECT, which means it will not be marked CE. In > normal mode, the outer packet is marked as the inner, and this might result in > an outer CE marking. Can you please, clarify why the description is inaccurate? According to RFC 6040 in compatibility mode outer packet are marked as not ECN-capable (Not-ECT). On the other hand, since using compatibility mode is SHOULD here and currently it is assumed that IPsec tunnels are used with normal mode (RFC 4301, RFC 6040), then some additional guidelines are given what to do if peer still uses normal mode. Am I missing something? I think my confusion here was that I read the second sentence ("If upon egress...") as also describing RFC6040, which I see now it does not. My apologies; perhaps splitting it into two paragraphs would help. However, the need for this text is related to difficulty mapping outer to inner; see also below. I moved this sentence to a new paragraph. > It's a shame that there is no attempt to figure out a mapping between inner > and > outer that would make normal mode work, as this reviewer is optimistic that > ECN > marks will become increasingly important. But regardless, this section should > be clear and make correct statements. I'm not sure this is generally possible given that one outer TCP tunnel can include many inner TCP tunnels, so you have to decide which of them to inform. The things get worse if AggFrag mechanism is in use (draft-ietf-ipsecme-iptfs-13, in IESG evaluation). This isn't a DISCUSS, so you can choose to ignore this advice or not. However, my concern is that IPSec is going to miss out on the low-latency services operators are now enabling through ECN. Not exactly :-) Note, that TCP is not a default transport for IPsec and in case ESP is sent over IP or UDP, all the modern ECN techniques must work well (I guess you mean L4S networks?). TCP is a backup transport in case no other is available and due to the inherent problems (TCP-in-TCP) we don't expect to get good performance in this case, so there is no point to complicate the protocol. TCP encapsulation is for those cases when you need things to work somehow, not in the best way. If it were me I would design it this way: 1) Encapsulators SHOULD NOT mix ECT(0), Not-ECT, and ECT(1) inner packets in the same outer packet. 2) If they do, the outer packet MUST be marked Not-ECT. 3) If all packets are marked CE, mark the outer packet CE. 4) If CE packets are mixed with "something else", mark it "something else". 5) Decapsulators follow Figure 4 in RFC6040, except they SHOULD NOT log an event or raise an alarm when the outer packet is ECT(1) and one of the inner packets is CE. Per 3168, if an inner packet is fragmented, any CE applied to a fragment is applied to the reassembled packet. This might work, but please, see above. > (Appendix A) Why not provide an in-band way to determine TLS support? > There > could be another port number, or different magic bytes to indicate that TLS > handshake messages follow. Actually, with this draft in-band switching to TLS is really a downgrade, rather than an upgrade (surprise?). The reason is that actual protection of the traffic is provided by IPsec and both TCP and TLS are only used as transport mechanisms that allow IPsec to work in environments where it cannot be used otherwise. And TLS is worse, since it requires more resources and has bigger overhead. So, once you get through using plain TCP there is no sense to switch to TLS. Thanks for the info. It might be good to explicitly state this in Appendix A, but feel free to ignore that suggestion. Thank you! Valery. Regards, Valery.
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
