Support for OOO packets in TCP

[Tommaso Bonato]

Hello,

I wanted to know if it is possible to easily change the current TCP code to support out of order packets at the receiver. I know there is one MPTCP project already but my needs are a bit different and I just need TCP to temporarily support OOO packets. I thought I could just make the rx buffer bigger but that doesn't seem to work. Am I missing something?

Thanks!

[Tommaso Pecorella]

Yes, you're missing the part where you explain what the problem is.

TCP already reorders the packets, so OOO packets are "naturally" supported.

[Tommaso Bonato]

So, the situation is quite simple. 

I am simulating an incast where 8 nodes send to a single node. Each packet is sprayed randomly, so there is a very high chance of many packets arriving out of order. 

It seems to work fine for certain packets but then, at one point I get a packet with sequence number 5897, while the next expected sequence number was 15545( Add pkt 0x55c472987880 len=536 seq=5897, when NextRxSeq=15545, buffsize=0). This triggers the function TcpSocketBase::IsValidTcpSegment() to return false and then I get a delay of 1 seconds (which I assume is the retransmission delay) for the following packets. 

What I would want to achieve is that, no matter how much out of order a packet is, it is "always" accepted by TCP.

[Tommaso Pecorella]

"no matter how much out of order a packet is, it is "always" accepted by TCP." is an impossible request.

Packets will be accepted if and only if the RX window can hold them.

Now, consider that a the SeqNo is 32 bits, and the RX window (if I remember right) can be as large as 2^30.

If I'm not too sleepy, 5897+2^32-15545 > 2^30, so it is above the maximum, no matter what. So the segment will be discarded (If it's in the future). If it's an old one... well, it's correctly trashed because it has been received already (otherwise the NextRxSeq would be less than 5897).

Summarising, OOO packets are put in the RX buffer if:

1) there's space, and

2) they're in the acceptable range

That's how TCP works...