Re: Failed TCP connection reset when processing overlapping data segments

[Lucas Aubard <lucas.aubard@xxxxxxxx>]

Dear Anil, 

Did you receive my last 23/05/2025 email?
What did you choose to do concerning TCP overlaps?

Best regards,
Lucas

----- Mail original -----
> De: "Lucas Aubard" <lucas.aubard@xxxxxxxx>
> À: "Anil Madhavapeddy" <avsm2@xxxxxxxxxxxx>
> Cc: "mirageos-devel" <mirageos-devel@xxxxxxxxxxxxxxxxxxxx>, "Johan Mazel" 
> <Johan.Mazel@xxxxxxxxxxx>, "gilles guette"
> <gilles.guette@xxxxxxxxxxxxxxxxx>, "Pierre Chifflier" 
> <Pierre.Chifflier@xxxxxxxxxxx>
> Envoyé: Vendredi 23 Mai 2025 11:25:52
> Objet: Re: Failed TCP connection reset when processing overlapping data 
> segments

> 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