See below... — Dr. Joe Touch, temporal epistemologist www.strayalpha.com > On Jun 2, 2022, at 8:03 AM, Valery Smyslov <s...@elvis.ru> wrote: > > HI Joe, > > On Jun 2, 2022, at 12:55 AM, Valery Smyslov <s...@elvis.ru > <mailto:s...@elvis.ru>> wrote: >> >> HI Joe, >> >> one more question: >> >> You can also note that there are ways to mitigate the cost of >> resync when >> this implementation is tightly coupled with TCP, e.g., by ensuring >> every Nth >> IPsec packet starts at the beginning of a new TCP packet. >> >> How would this help? Can you please elaborate? > > If every 4th IPsec packet is always aligned to the TCP segment data start, > then resync checks could be simple and rapid - check only the first bytes for > a known pattern. > > That makes resync happen with lower overhead, i.e., rather than searching the > whole payload. > > Interesting idea, but how the receiving node would know that > sending node employs this method?
They don’t need to. Basically the receiver should “check a few places until it wants to give up”. There’s no rule that resync must be exhaustive, but if it succeeds, it averts the need for a new connection. > And, in my understanding some middleboxes can re-arrange TCP > segments, merging and splitting them, They DO this, as do some offloading devices, sometimes in ways that break TCP. But that doesn’t matter here - again, at the receiver, it either works or it doesn’t. > so the beginning of IPsec packet may still appear in the middle of > TCP segment (the same can happen > with retransmissions, but I guess you assume that sending TCP/IP > stack would take care in this case, but it adds complexity). Retransmissions don’t need to realign; the sender can just do this on first transmission. It’s just an optimization that helps the receiver potentially resync faster or not need to give up on resync as quickly. > > So, I think that the idea is interesting, but the additional > complexity and unreliability makes it not so attractive. It doesn’t need to be reliable to be useful, as per above. > > Regards, > Valery. > > Joe > -- > last-call mailing list > last-c...@ietf.org <mailto:last-c...@ietf.org> > https://www.ietf.org/mailman/listinfo/last-call > <https://www.ietf.org/mailman/listinfo/last-call>
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
