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
