Re: Failed TCP connection reset when processing overlapping data segments

[Lucas Aubard <lucas.aubard@xxxxxxxx>]

Dear Anil, 

Sorry I missed your answer!

I think the three reasons that you cite may be relevant but I do not have any 
relevant information on these three aspects.

To extend what I said about OS behaviors, we observe that some embedded stacks 
(lwIP, uIP, picoTCP) ignore overlapping data segments just as mirage-tcpip. 
However, this behavior choice is probably due to the resource constraints.

I compared RFC793 and RFC9293 regarding the two sentences (in parts 3.10 and 4) 
that I cited in my previous mail, and both sentences are present in both 
documents. So, I do not think that anything changed since 2013.
My main argument for accepting overlapping segment is the fact that these two 
sentences are present in the RFCs but I do not have any additional evidence.

Best regards, 
Lucas Aubard.

----- Mail original -----
> De: "Anil Madhavapeddy" <avsm2@xxxxxxxxxxxx>
> À: "Lucas Aubard" <lucas.aubard@xxxxxxxx>
> Cc: "Hannes Mehnert" <hannes@xxxxxxxxxxx>, "mirageos-devel" 
> <mirageos-devel@xxxxxxxxxxxxxxxxxxxx>, "Johan Mazel"
> <Johan.Mazel@xxxxxxxxxxx>, "gilles guette" <gilles.guette@xxxxxxxxxxxxxxxxx>, 
> "Pierre Chifflier"
> <Pierre.Chifflier@xxxxxxxxxxx>
> Envoyé: Mercredi 16 Avril 2025 15:20:05
> Objet: Re: Failed TCP connection reset when processing overlapping data 
> segments

>> On Apr 16, 2025, at 8:28 AM, Lucas Aubard <lucas.aubard@xxxxxxxx> wrote:
>> 
>> The behavior you describe for processing overlapping data segments makes 
>> sense
>> to me.
> 
> I must admit I'm still in the dark as to why this makes more sense today to do
> this than in 2013, when we dropped that data in preference for an unambiguous
> retransmission in case the stack was under attack. What's changed such that we
> can now accept overlapping TCP segments for the same data?
> 
> There are a few reasons I can think of that may explain it (but I haven't
> checked):
> - perhaps datacenter Linux wants to avoid retransmissions at all costs
> - perhaps the security model has been revved somehow to delegate this to the
> higher levels of the stack (DTLS)
> - or perhaps out of order transmissions are more common (multipath?) so we now
> need to deal with it.
> 
> I'm not really sure which of these are true or not, but without determining
> this, it seems unwise to depend on other stacks' behavior here.
> 
> best,
> Anil