Re: the ECN rules for aggregated packets, I got intrigued by this problem and wrote a draft. The rules I proposed earlier are, unsurprisingly, not the whole story.
On Wed, Aug 10, 2022 at 7:05 AM Martin Duke <martin.h.d...@gmail.com> wrote: > Sounds good to me, we're all set modulo the thread with Joe. > > On Wed, Aug 10, 2022, 01:25 Valery Smyslov <s...@elvis.ru> wrote: > >> Hi Martin, >> >> >> >> please see inline. >> >> >> >> On Mon, Aug 8, 2022 at 5:12 AM Valery Smyslov <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
