Repository navigation
SFDP does not implement any Conntrack TIME-WAIT Timeout #3693
Description
The file sfdp_types.api already defines SFDP_API_SESSION_STATE_TIME_WAIT value, but no code currently sets it, so there must be a bug or a missing feature.
Let me describe how this is affecting upcoming SFDP performance tests in CSIT. While packet loss there usually happens as a RX miss on VPP, it is possible that it happens as a RX miss on TRex (simulating responder TCP stack). If that affects the last ACK, responder will retransmit its FIN+ACK, but if VPP has deleted the session already, this FIN+ACK will create a session in the opposite direction. I am not currently sure what is the TIME_WAIT value on TRex simulated initiator TCP stack, but CSIT does forcefully abort all the traffic at the end of the trial, so in unfortunate timing there is no RST packet generated by the initiator stack notifying VPP that the reverse session is wrong. When next trial starts in a TPUT test, this reverse direction session is observed to prevent forwarding in old forward (new reverse) direction, causing unavoidable losses even at low loads, thus causing the performance test to fail.
I tried to create a python test (for make test) that replicates the situation, and I am also trying to sketch a fix that adds such "connection tracking time-wait timeout" to SFDP (to sfdp-tcp-check service, triggered by sfdp-l4-lifecycle service, also adding one more per-tenant configurable timeout value).
Activity
vrpolakatcisco commentedon Mar 9, 2026
TRex timeouts are defined here where TCPTV_2MSL ends up corresponding to half a second.
vrpolakatcisco commentedon May 14, 2026
A fix with scope appropriate for CSIT test stability, many corner cases left as TODOs: 45047: sfdp_services: add basic support for time-wait | https://gerrit.fd.io/r/c/vpp/+/45047
vrpolakatcisco commentedon Oct 27, 2026
This [5] change has improved the pass rate somewhat, but as trending [6] shows NDRPDR tests can still fail or report low performance.
A link to a recent failure is here [7] but it is hard to tell what went wrong, as the behavior repaired itself before teardown trial.
I suspect the "hard failures" due to session created in wrong direction was fixed by [5], but there are some "soft issues" remaining. One possibility is caused by RST packets I remember seeing in an old verify run. I think TRex is generating those when time runs out while some sessions still retransmitting, both client side and server side send RSTs, and depending on order those arrive at VPP the next trial could have that session affected again (although I do not see exactly how, double-removal is supposed to be fixed already).
Or it could be the simple issue of final ACK when lost after VPP is retransmitted by an endpoint but never forwarded by VPP (VPP removed the session quickly so re-ack is non-syn-fsol).
[5] 45916: sfdp_services: change fsol-non-syn behavior in l4-lifecycle | https://gerrit.fd.io/r/c/vpp/+/45916
[6] sfdp tcp l4ip4 tput on xeons
[7] https://logs.fd.io/vex-yul-rot-jenkins-1/csit-vpp-perf-ndrpdr-weekly-master-2n-icx/40044263100/log.html.gz#s1-s1-s1-s6-s4-t1-k2-k10-k16