diff options
Diffstat (limited to 'content/en/blog/20220520-oping-flm.md')
| -rw-r--r-- | content/en/blog/20220520-oping-flm.md | 33 |
1 files changed, 4 insertions, 29 deletions
diff --git a/content/en/blog/20220520-oping-flm.md b/content/en/blog/20220520-oping-flm.md index f3c81c0..31268e4 100644 --- a/content/en/blog/20220520-oping-flm.md +++ b/content/en/blog/20220520-oping-flm.md @@ -1,7 +1,7 @@ --- date: 2022-05-20 title: "What is there to learn from oping about flow liveness monitoring?" -linkTitle: "cleaning up flows" +linkTitle: "learning from oping (1): cleaning up" author: Thijs Paelman --- @@ -71,42 +71,17 @@ 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.. -### Asymmetrical QoS -There will probably follow some more [discussion](https://ouroboros.rocks/community/) -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)) -flows from unresponsive clients. -I then discovered that `flow_accept(qosspec_t * qs, const struct timespec * timeo)` only uses qs to write to, -not to read the server QoS expectations. -Thus, at the moment, only the client sets the QoS (if the layer can give it). -This will change, such that the server sends its QoS to the client too. - -When we're talking about FLM, this might result in the server saying something like: -> I don't trust you, I'm gone if I don't hear from you in 4 minutes, and if you want to want to wait for me 2 days, suits me just fine - -where the server sets a FLM of 4 min and the client sets a FLM of 2 days. -In this scenario, the client has to send[^2] every minute a keep-alive to keep the server interested ([unless it cleans up anyway](#cleaning-up-flows)). -The server, on the other hand, only needs to send a keep-alive every 12 hours to keep the flow open (assuming no other traffic at all). - -There might be cases where you want to sync this timeout (like taking the smallest value), -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. +We might for example use this mechanism to show to the user that the peer seems to be down[^overleaf] and even take measures (like saving or removing state), but also allow to just wait until the peer is live again. ### 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) +but it's up to you to decide if you deallocate your side of the flow and when. Excited for my first blog post & always learning, Thijs -[^1]: like for wireless links, with a potential different BER or loss in each direction - or even IPsec, where you can have encryption in one direction, but not the other -[^2]: fixed at 1/4 of the time-out period at the moment, see [previous post](https://ouroboros.rocks/blog/2022/02/28/application-level-flow-liveness-monitoring/) +[^overleaf]: I'm thinking about things like the Overleaf banner: `Lost Connection. Reconnecting in 2 secs. Try Now` |