On 18 Mar 2022, at 17:28, Miklós Tirpák <miklos.tir...@emnify.com<mailto:miklos.tir...@emnify.com>> wrote:
Getting back to some of the topics, The main concern about RST was to recover from a 3rd party sending RSTs into the session. This would require the sender to spoof the src IP, right? Are you aware of any scenario when an RST followed by subsequent data could happen during a "normal" session and it should really keep the session established? - Any FIN or RST will move session to transitory without recovery to established Right, so if one side says “FIN” a.k.a. I’m done with sending data to you, while the other party still has data to send, then you just cut it off. Not sure how often this occurs in real world... Agree, I was also concerned about this. No idea how prevalent this is. I could add a counter I suppose that would count number of packets in transitory state. Or packets hitting a non garbage collected entry within the time window between established and transitory. I also have another patch that expands on the syslog session logging, which could be used to do post session analysis to learn better how well the state machine fares. In half-closed packets are still allowed to pass, just with a transitory timeout instead of established. So if one side sends FIN, and the other sends a packet an hour later, that will not work. But if the other side sent it 3 minutes later it would. Assuming default timers. Maybe Miklos can provide some insight into this as they seem to do a lot of “device is rarely communicating”. If the FIN was received, then this should be okey I think. Both sides are aware that the session is closing. If the FIN and all of its re-transmits are lost, then this can become a problem indeed. When the other side sends data after an hour, the packets will be dropped and it can take a long time until the re-transmission timer expires and the session is re-established by the client. (This also means a lot of extra packets, which matters for IoT.) I would, however still prefer to make this change and rather speed-up the reconnect by sending an RST, as I have indicated before. The client behavior would be the same, it would anyway get an RST from the other side. If you agree, then let us create a separate patch for the RST and we can contribute. I like the idea of VPP sending RST for cases where the session doesn’t exist or for some reason the state is invalid. It might also be a good idea to implement VPP sending TCP keepalives for idle sessions to discover whether the peers are still active, but that is a separate task. Thanks, Miklos Yes, that would be good to know. Best regards, Ole
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#21070): https://lists.fd.io/g/vpp-dev/message/21070 Mute This Topic: https://lists.fd.io/mt/88218698/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
