Connection Tracking: Too loose, UDP and Aging

[mitalum]

Does the model remove the flow entirely on the FIN flag? Or does it wait for some time after the FIN flag so that the final ACKs can be forwarded? Is this too loose? The connection should be active only until an ACK packet in each direction covers the sequence number of the FIN packet in the other direction or timeout, whichever occurs first. I believe it would take ~7 states per direction to strictly track the TCP state. Should TCP connection tracking also support TCP window tracking?

What about support for UDP "connections" and the behavior of aging of both UDP and TCP flows?

What is the desired behavior when an ACL or route table configuration changes that potentially affects the forwarding behavior of an established flow? The specifications describe a slow path and fast path where the ACL and route lookups are avoided in the fast path (for performance). The current behavioral model appears to execute the ACL and route lookup on each and every packet. As a result there is no behavioral difference between the slow path and a fast path. This implies that implementations with both a fast and a slow path must re-evaluate ACL/route lookups for flows whenever configuration changes occurs that may affect the flows. Is this correct? Should the behavioral model explicitly model a fast and a slow path?

https://github.com/Azure/DASH/blob/6b2a638d6f620469fdff59716c65bb7286b5ef61/sirius-pipeline/sirius_conntrack.p4#L42

See PR PNA compatible connection tracking #21

[KrisNey-MSFT]

We are in agreement that this will require more polishing as we move forward. Will bring up for discussion in the Community meeting again for Comments/help. @GeraldatMicrosoft

[mariobaldi]

The fact that ACL are applied to each and single packet might be due to a mistake (having forgotten a "!") that should be fixed by this PR: 30b13ba
The rest of the code seems to indeed have been written to support ACL matching only before installing connection state.