aboutsummaryrefslogtreecommitdiff
path: root/content/en/blog
diff options
context:
space:
mode:
authorThijs Paelman <thijs.paelman+git@hotmail.be>2022-06-14 00:43:47 +0200
committerThijs Paelman <thijs.paelman+git@hotmail.be>2022-06-14 00:43:47 +0200
commitb7af0c3cf9c13779ec84fe4517492116a063ea3e (patch)
tree5025fa5ea4c7965e289febb3631dffe61e1b2c04 /content/en/blog
parentdfe6c175407975475bd61b67b3cd1da7d119f749 (diff)
downloadwebsite-b7af0c3cf9c13779ec84fe4517492116a063ea3e.tar.gz
website-b7af0c3cf9c13779ec84fe4517492116a063ea3e.zip
blog: add oping FLM conclusion
Diffstat (limited to 'content/en/blog')
-rw-r--r--content/en/blog/20220520-oping-flm.md12
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