From a746e32ad3b436740a6d9cda2f72533a243d0e22 Mon Sep 17 00:00:00 2001 From: colin constable Date: Fri, 23 Feb 2024 17:46:39 -0800 Subject: [PATCH 1/3] feat: created proposed decision of max supported devices per atSign --- decisions/2024-02-Devices-per-atSign.md | 27 +++++++++++++++++++++++++ 1 file changed, 27 insertions(+) create mode 100644 decisions/2024-02-Devices-per-atSign.md diff --git a/decisions/2024-02-Devices-per-atSign.md b/decisions/2024-02-Devices-per-atSign.md new file mode 100644 index 0000000..5ba9ae3 --- /dev/null +++ b/decisions/2024-02-Devices-per-atSign.md @@ -0,0 +1,27 @@ +# Devices per atSign + + +* **Status:** Draft +* **Last Updated:** 2024-02-23 +* **Objective:** A standard supported maximum of devices per atSign to engineer to. + +## Context & Problem Statement + With each atSign it is possible to have N devices associated and connected at any one time. With personal atSigns this is limited by the number of devices a person may have. + But in an Enterprise setting an atSign could have N devices. With applications like SSH No Ports a company call have 10k devices all on one atSign. +## Goals +Decide on a reasonable number of devices supported simulataneously on one atSign and it associated atServer. +### Non-goals +We do not want to change the existing architecture and introduce complexity to reduce the risk of an a single atSign's atServer being offline and effecting huge numbers of devices in turn. +## Other considerations +Prevent a person using single atSign and connecting thousands of devices at low cost and high risk and putting stress on the rest of the infrastructure + +* ### Option 1 + Keep existing atServer configuration see at what point things fail and decide on a % of that number of devices. + + +## Proposal Summary +Soft/advertised limit of 25 concurrent active devices per atSign +## Proposal in Detail +The existing limit of 200 TCP sessions and the existing limits of the docker container holding the atServer provide good support for up to 50 devices, so the suggested maximum should be 50% of that at 25 devices per atSign. +This provides amble devices for most if not all use cases and limits risk to a maximum of 25 devices if an atServer fails whilst also protecting from potiential abuse of over subscribed atSigns. + From 756373f6bd280ae2d16e57a1887db489c7f2cd76 Mon Sep 17 00:00:00 2001 From: colin constable Date: Fri, 23 Feb 2024 18:05:21 -0800 Subject: [PATCH 2/3] fix: a few typos fixed --- decisions/2024-02-Devices-per-atSign.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/decisions/2024-02-Devices-per-atSign.md b/decisions/2024-02-Devices-per-atSign.md index 5ba9ae3..c1a61a3 100644 --- a/decisions/2024-02-Devices-per-atSign.md +++ b/decisions/2024-02-Devices-per-atSign.md @@ -7,7 +7,7 @@ ## Context & Problem Statement With each atSign it is possible to have N devices associated and connected at any one time. With personal atSigns this is limited by the number of devices a person may have. - But in an Enterprise setting an atSign could have N devices. With applications like SSH No Ports a company call have 10k devices all on one atSign. + But in an Enterprise setting an atSign could have N devices. With applications like SSH No Ports a company could have 10k devices all on one atSign. ## Goals Decide on a reasonable number of devices supported simulataneously on one atSign and it associated atServer. ### Non-goals @@ -23,5 +23,5 @@ Prevent a person using single atSign and connecting thousands of devices at low Soft/advertised limit of 25 concurrent active devices per atSign ## Proposal in Detail The existing limit of 200 TCP sessions and the existing limits of the docker container holding the atServer provide good support for up to 50 devices, so the suggested maximum should be 50% of that at 25 devices per atSign. -This provides amble devices for most if not all use cases and limits risk to a maximum of 25 devices if an atServer fails whilst also protecting from potiential abuse of over subscribed atSigns. +This provides ample devices for most if not all use cases and limits risk to a maximum of 25 devices if an atServer fails whilst also protecting from potential abuse of over subscribed atSigns. From f0cc3f772f11043978b711a5dc132728316da224 Mon Sep 17 00:00:00 2001 From: Chris Swan <478926+cpswan@users.noreply.github.com> Date: Mon, 26 Feb 2024 11:47:41 +0000 Subject: [PATCH 3/3] docs: Linted Markdown --- decisions/2024-02-Devices-per-atSign.md | 45 ++++++++++++++++++------- 1 file changed, 33 insertions(+), 12 deletions(-) diff --git a/decisions/2024-02-Devices-per-atSign.md b/decisions/2024-02-Devices-per-atSign.md index c1a61a3..1adacac 100644 --- a/decisions/2024-02-Devices-per-atSign.md +++ b/decisions/2024-02-Devices-per-atSign.md @@ -1,27 +1,48 @@ # Devices per atSign - * **Status:** Draft * **Last Updated:** 2024-02-23 -* **Objective:** A standard supported maximum of devices per atSign to engineer to. +* **Objective:** A standard supported maximum of devices per atSign to +engineer to. ## Context & Problem Statement - With each atSign it is possible to have N devices associated and connected at any one time. With personal atSigns this is limited by the number of devices a person may have. - But in an Enterprise setting an atSign could have N devices. With applications like SSH No Ports a company could have 10k devices all on one atSign. + +With each atSign it is possible to have N devices associated and connected at +any one time. With personal atSigns this is limited by the number of devices +a person may have. But in an Enterprise setting an atSign could have N devices. +With applications like SSH No Ports a company could have 10k devices all on +one atSign. + ## Goals -Decide on a reasonable number of devices supported simulataneously on one atSign and it associated atServer. + +Decide on a reasonable number of devices supported simulataneously on one +atSign and it associated atServer. + ### Non-goals -We do not want to change the existing architecture and introduce complexity to reduce the risk of an a single atSign's atServer being offline and effecting huge numbers of devices in turn. -## Other considerations -Prevent a person using single atSign and connecting thousands of devices at low cost and high risk and putting stress on the rest of the infrastructure + +We do not want to change the existing architecture and introduce complexity +to reduce the risk of an a single atSign's atServer being offline and +effecting huge numbers of devices in turn. + +## Other considerations + +Prevent a person using single atSign and connecting thousands of devices at +low cost and high risk and putting stress on the rest of the infrastructure. * ### Option 1 - Keep existing atServer configuration see at what point things fail and decide on a % of that number of devices. - + + Keep existing atServer configuration see at what point things fail and + decide on a % of that number of devices. ## Proposal Summary + Soft/advertised limit of 25 concurrent active devices per atSign + ## Proposal in Detail -The existing limit of 200 TCP sessions and the existing limits of the docker container holding the atServer provide good support for up to 50 devices, so the suggested maximum should be 50% of that at 25 devices per atSign. -This provides ample devices for most if not all use cases and limits risk to a maximum of 25 devices if an atServer fails whilst also protecting from potential abuse of over subscribed atSigns. +The existing limit of 200 TCP sessions and the existing limits of the docker +container holding the atServer provide good support for up to 50 devices, so +the suggested maximum should be 50% of that at 25 devices per atSign. +This provides ample devices for most if not all use cases and limits risk to +a maximum of 25 devices if an atServer fails whilst also protecting from +potential abuse of over subscribed atSigns.