Problematic healing scenarios

[denis-tingaikin]

Problem statement

Let's consider all healing scenarios exclude registry cases (because registry cases still TODO)

Healing complexity

Let's try to calculate healing complexity. Where 1*t is a time to wait for a heal for the one next application.

Local use-cases

1. NSE dies, complexity is 3t
2. NSMGR dies, complexity is 3t
3. Forwarder dies, complexity is 1t
4. NSC dies, complexity is 0

Remote use-cases

1. NSE dies, complexity is 6t
2. Remote NSMGR dies, complexity is 3t
3. Remote Forwarder dies, complexity is t
4. Local NSMGR dies, complexity is 3t
5. Local Forwarder dies, complexity is t
6. NSC dies, complexity is 0

Interdomain use-cases

1. NSE dies, complexity is 7t
2. Remote NSMGR dies, complexity is 3t
3. Remote Forwarder dies, complexity is t
4. Proxy NSMGR dies, complexity is t
5. Local NSMGR dies, complexity is 3t
6. Local Forwarder dies, complexity is t
7. NSC dies, complexity is 0

Visualization

Worst-case scenario analysis

1. Most problem scenario is 'NSE dies' because only NSMGR that selects NSE can heal the connection and currently remote NSMGR cannot simply transfer the healing control to local NSMGR, so all elements between local NSMGR and NSE will wait for healing timeout.

2. The next points for optimization are 'Local NSMGR dies' and 'Remote NSMGR dies'. Recently we've added serialization of the requests. So we can have a heal race situation wherein the worst case forwarder will block requests from the client by serialization during healing it's NSMGR.

[denis-tingaikin]

@edwarnicke . @haiodo , @fkautz cc