Taking LIF down is not related to LinkDownTime - interface on host is still up, there is no link problem. Timeout most like corresponds to IO request timeout after which MPIO on host retries on different path.
In case of SFO there is short pause when access to aggregate is switched to partner, both (all) paths are alive and function correctly.
When the customer has the LIF down test, that means taking down the active LIF. The client IO was interuppted for 15s. And the IO downtime will change by the modification of client LinkDownTime option. I am not sure what's the expected behavior when taking down the active LIFs.
And when SFO happens on the local node, the iSCSI LIFs will take down and the aggr will relocate to the partner. per the test, there is almost no IO downtime(less the 1s) in the client observation. Is this an expected behavior?
Ah, OK, it is just misleading parameter name. Windows iSCSI initiator LinkDownTime in reality defines IO request timeout, so it is exactly as I explained - when path becomes unavailable, host waits for configured timeout before switching over to another path. When you perform SFO all paths continue to be available, so it is just time required to flip disk ownership between controllers.
Yes, you are right, sorry for mixing up 7-Mode and C-Mode. Well, I think filer may notify host that preferred path changed so host simply continues IO over remaining LIF. But yes, I would be interested in final answer too.