diff options
| -rw-r--r-- | content/en/blog/20220520-oping-flm.md | 12 |
1 files changed, 10 insertions, 2 deletions
diff --git a/content/en/blog/20220520-oping-flm.md b/content/en/blog/20220520-oping-flm.md index eb9e25a..f3c81c0 100644 --- a/content/en/blog/20220520-oping-flm.md +++ b/content/en/blog/20220520-oping-flm.md @@ -71,9 +71,9 @@ We can see here that the decision is taken to 'clean up' (= `flow_dealloc`) thos But, as we can see, it's an application decision! We might as well decide to keep it open for another 10 min to see if the client (or the network in between) recovers from interruptions, e.g.. -### Assymetrical QoS +### Asymmetrical QoS There will probably follow some more [discussion](https://ouroboros.rocks/community/) -on assymetric QoS[^1], but here we're only talking about assymetric FLM. +on asymmetric QoS[^1], but here we're only talking about asymmetric FLM. When I was working on the server code, I tried to set a FLM of 10 sec on the server side, such that it would time-out (and [remove](#keeping-timed-out-flows)) @@ -94,6 +94,14 @@ There might be cases where you want to sync this timeout (like taking the smalle but it still needs to be determined if this should be done at the application level or ouroboros and if so, how. But for a 'raw' flow, we go with the 'none-of-your-business, just send in time' principle. +### Conclusion + +As an application, you have total freedom (and responsibility) over your flows. +Ouroboros will only inform you that your flow is timing out (and your peer thus appears to be down), +but it's up to you to decide if you deallocate your side of the flow and when. +The asymmetric QoS will need more discussion and experimenting before we know what the best approach would be. +Do we need reconciliation algorithms, and between which parties do they work? (what the application wants, what the layer below can deliver and what the peer can promise) + Excited for my first blog post & always learning, Thijs |