> On 18 Mar 2022, at 17:29, Miklós Tirpák <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?
No. But I am no tcp expert. :-) >>>>>> - 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. Yes, although the proposal does not wait for the FIN to be ack’ed. > 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. It would be cool if we could, but can without essentially making it into a tcp proxy? Cheers Ole >> Yes, that would be good to know. >> >> Best regards, >> Ole > > > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#21072): https://lists.fd.io/g/vpp-dev/message/21072 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] -=-=-=-=-=-=-=-=-=-=-=-
