Hi Martin,
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
<mailto:martin.h.d...@gmail.com> > wrote:
Sounds good to me, we're all set modulo the thread with Joe.
So, after conversation with Joe, what do you think we shall do with the
text describing
"TCP meltdown" - do you still think it's inaccurate? If so can you
fix it? Or shall we leave it as is?
Regards,
Valery.
On Wed, Aug 10, 2022, 01:25 Valery Smyslov <s...@elvis.ru
<mailto:s...@elvis.ru> > wrote:
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
