From dec2f6ea1e85570c49233dd2972a312558a1ed85 Mon Sep 17 00:00:00 2001 From: Paul Date: Sun, 22 Mar 2026 12:12:53 +1300 Subject: [PATCH 1/2] First go at addressing concurrent connection issue. --- asciidoc/volume0/tf0-ch-d-glossary.adoc | 2 +- .../tf1-ch-b-ref-standards-conformance.adoc | 4 + ...tf2-ch-a-mdpws-concurrent-connections.adoc | 138 ++++++++++++++++++ asciidoc/volume2/tf2-ch-a-mdpws.adoc | 2 + 4 files changed, 145 insertions(+), 1 deletion(-) create mode 100644 asciidoc/volume2/concurrent-connections/tf2-ch-a-mdpws-concurrent-connections.adoc diff --git a/asciidoc/volume0/tf0-ch-d-glossary.adoc b/asciidoc/volume0/tf0-ch-d-glossary.adoc index 6829d99c..432945cb 100644 --- a/asciidoc/volume0/tf0-ch-d-glossary.adoc +++ b/asciidoc/volume0/tf0-ch-d-glossary.adoc @@ -468,7 +468,7 @@ implements a service-oriented <> architecture composed of service p | | [[term_transport_address, Transport Address]] Transport Address -| A physical endpoint address that can be used to communicate with a <>. +| A physical or virtual endpoint address that can be used to communicate with a <> or <> . | XAddr | | diff --git a/asciidoc/volume1/tf1-ch-b-ref-standards-conformance.adoc b/asciidoc/volume1/tf1-ch-b-ref-standards-conformance.adoc index c522e670..a266dded 100644 --- a/asciidoc/volume1/tf1-ch-b-ref-standards-conformance.adoc +++ b/asciidoc/volume1/tf1-ch-b-ref-standards-conformance.adoc @@ -70,6 +70,10 @@ No content from those three standards - including their requirements - is norma * [[[ref_rfc_5905, RFC 5905]]] D. Mills et al., RFC 5905, Network Time Protocol Version 4: Protocol And Algorithms Specification, June 2010, available at https://www.rfc-editor.org/rfc/rfc5905 +* [[[ref_rfc_6585, RFC 6585]]] M. Nottingham, R. Fielding, RFC 6585, Additional HTTP Status Codes, April 2012, available at https://www.rfc-editor.org/rfc/rfc6585 + +* [[[ref_rfc_7231, RFC 7231]]] R. Fielding, J. Reschke, RFC 7231, Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content, June 2014, available at https://www.rfc-editor.org/rfc/rfc7231 + * [[[ref_rfc_9110, RFC 9110]]] R. Fielding, M. Nottingham, J. Reschke, RFC 9110, HTTP Semantics, June 2022, available at https://www.rfc-editor.org/rfc/rfc9110 * [[[ref_oasis_dpws_2009,OASIS DPWS:2009]]] OASIS Standard, Devices Profile for Web Services Version 1.1, OASIS Standard, 1 July 2009, available at http://docs.oasis-open.org/ws-dd/dpws/wsdd-dpws-1.1-spec.html diff --git a/asciidoc/volume2/concurrent-connections/tf2-ch-a-mdpws-concurrent-connections.adoc b/asciidoc/volume2/concurrent-connections/tf2-ch-a-mdpws-concurrent-connections.adoc new file mode 100644 index 00000000..d17f29bd --- /dev/null +++ b/asciidoc/volume2/concurrent-connections/tf2-ch-a-mdpws-concurrent-connections.adoc @@ -0,0 +1,138 @@ +[#vol2_ch_a_mdpws_concurrent_connections] +==== MDPWS Concurrent Consumer Connections + +SDC allows a <> to open multiple, concurrent TCP +connections to a <>'s hosted services. +While this offers flexibility for implementations, <> +may constrain the number of concurrent TCP connections to ensure availability of its +<>. + +This section describes scenarios and recommendations for managing concurrent connections +between consumers and providers. + +.R0201 +[sdpi_requirement#r0201,sdpi_req_level=may] +[sdpi_req_type=risk_mitigation,sdpi_ses_type=effectiveness,sdpi_ses_test=wire] +**** +[NORMATIVE] +==== +The <> of a <> may limit the number of +concurrent TCP connections from an individual <> to its hosted services to ensure availability and +responsiveness of its <>. +==== + +[NOTE] +==== +* A <> may choose to limit the number of concurrent connections +accepted from an individual <> to one or more, or +allow unlimited connections, based on its resource capabilities and design goals. +* To enforce TCP connection limits, a provider may identify a <> by its: +** <> and/or, +** `[source endpoint]` message property (see <>) and/or, +** client credentials used for TLS authentication. +* Securing the connection may be the most expensive part of an operation, so a <> may +drop concurrent connections from a <> that exceed its limits, or respond with +HTTP status code `429 (Too Many Requests)` (after securing the connection) to signal the <> +to reduce its connection count and/or frequency. +==== + +// todo: specify how client credentials can identify consumer based on the work from the +// security working group: https://github.com/ornet-ev/wg-certificates + +**** + +.R0202 +[sdpi_requirement#r0202,sdpi_req_level=shall] +[sdpi_req_type=risk_mitigation,sdpi_ses_type=effectiveness,sdpi_ses_test=wire] +**** +[NORMATIVE] +==== +The <> of a <> shall consider +the risks of opening multiple, concurrent connections to a <>'s +hosted services, including the potential impact on both the <>'s +and the <>'s ability to deliver their respective +<>. + +==== + +[NOTE] +==== +A consumer may choose to limit the number and/or frequency of concurrent connections it +opens to a <>'s hosted services when it receives a +response with HTTP status code `429` (Too Many Requests). + +==== + +**** + +===== Motivation + +====== Resource Constraints + +Devices with limited processing and/or memory resources (e.g., pulse oximeters, infusion pumps, etc.) may support +only a small number of active TCP connections (e.g., 10-20). +These connections are allocated to support the <>s +<> including: hosted services (e.g., `GET` and subscription management), +publishing updates, discovery and logging. + +A <> opening multiple concurrent connections to a +<>'s hosted services may consume a disproportionate number of +available connections, reducing the number of <>s that a +<> can support and/or compromising its <>. + +====== Consumer Rationale for Multiple Connections + +A <> may open multiple concurrent connections to a provider's hosted services to: + +* separate time-critical operations (e.g., `SET SERVICE` operations) from less critical operations (e.g., subscription +renewals), +* reduce the risk of urgent messages being delayed by less urgent traffic, or +* provide redundancy for critical operations. + +===== Interoperability Strategy + +====== Status Signalling + +A <> experiencing excessive load: + +* may respond with HTTP status code `429` (Too Many Requests, <>), and +* may include a `Retry-After` header (<>) to indicate when the consumer may retry the request. + +Consumers should interpret this response as a signal to adapt their connection strategy. For example, a consumer may: + +* reduce the number of concurrent connections, +* use a single connection for all operations, +* implement backoff and retry logic. + +A <> receiving a `429` response should not interpret this as a operation failure, but rather as an indication that the provider is under load and needs the consumer to adjust its behaviour. +The consumer may use information in the `Retry-After` header, if present, to determine when to retry the request, but could also consider implementing an exponential backoff strategy to avoid overwhelming the provider with retries. + +When a <> includes the `Retry-After` header (<>) in a `429 (Too Many Requests)` response, it should provide the retry period in seconds. RFC 7231 allows for an +HTTP-date format in the `Retry-After` header, but this is not recommended for SDC to avoid the complexity of parsing +HTTP-date values and potential clock synchronization issues between devices. + +====== Recommendations + +[cols="1,1,1"] +|=== +| Scenario | Provider Behaviour | Consumer Behaviour + +| Resource-constrained provider +| Respond with `429`, with no `Retry-After` header, to requests from consumers exceeding connection limits +| Reduce concurrent connections; multiplex operations on single connection + +| Normal provider (no constraints) +| Accept multiple connections per consumer +| May use multiple connections for priority separation if desired + +| Provider under load (temporary) +| Respond with `429` to new connection attempts and include a `Retry-After` header +| Implement exponential backoff; retry after the specified time + +|=== + +===== Related Requirements + +* RefRequirement:r1001[]: Single connection to consumer for sending reports + + diff --git a/asciidoc/volume2/tf2-ch-a-mdpws.adoc b/asciidoc/volume2/tf2-ch-a-mdpws.adoc index 2b07ce34..e190aa5d 100644 --- a/asciidoc/volume2/tf2-ch-a-mdpws.adoc +++ b/asciidoc/volume2/tf2-ch-a-mdpws.adoc @@ -91,6 +91,8 @@ CAUTION: This appendix does not specify any processes towards certificate govern include::connect-time-algorithm/tf2-ch-a-mdpws-connect-time-algorithm.adoc[] +include::concurrent-connections/tf2-ch-a-mdpws-concurrent-connections.adoc[] + include::mdib-report-retrofit/tf2-ch-a-mdpws-mdib-report-retrofit.adoc[] include::mdpws-compression/tf2-ch-a-mdpws-compression.adoc[] From 79a6619f34f53fa0f1ae59e2893395d1ab6d62fe Mon Sep 17 00:00:00 2001 From: Paul Date: Thu, 2 Apr 2026 20:58:22 +1300 Subject: [PATCH 2/2] Reverted addition of virtual to transport address definition; it didn't add any value. Tweaked wording of introduction to improve clarity and avoid "ensure". Removed repetition of motivation in R0201; its already in the intro and makes more sense there. Clarified operation => SDC service operation (language from annex B of 20701). Added change log entry. --- CHANGELOG.md | 1 + asciidoc/volume0/tf0-ch-d-glossary.adoc | 2 +- .../tf2-ch-a-mdpws-concurrent-connections.adoc | 7 +++---- 3 files changed, 5 insertions(+), 5 deletions(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index db0033ef..7f0f0443 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -21,6 +21,7 @@ Each section shall contain a list of action items of the following format: `> architecture composed of service p | | [[term_transport_address, Transport Address]] Transport Address -| A physical or virtual endpoint address that can be used to communicate with a <> or <> . +| A physical endpoint address that can be used to communicate with a <> or <> . | XAddr | | diff --git a/asciidoc/volume2/concurrent-connections/tf2-ch-a-mdpws-concurrent-connections.adoc b/asciidoc/volume2/concurrent-connections/tf2-ch-a-mdpws-concurrent-connections.adoc index d17f29bd..0370914c 100644 --- a/asciidoc/volume2/concurrent-connections/tf2-ch-a-mdpws-concurrent-connections.adoc +++ b/asciidoc/volume2/concurrent-connections/tf2-ch-a-mdpws-concurrent-connections.adoc @@ -4,7 +4,7 @@ SDC allows a <> to open multiple, concurrent TCP connections to a <>'s hosted services. While this offers flexibility for implementations, <> -may constrain the number of concurrent TCP connections to ensure availability of its +may constrain the number of concurrent TCP connections to help mitigate risks to the availability of its <>. This section describes scenarios and recommendations for managing concurrent connections @@ -17,8 +17,7 @@ between consumers and providers. [NORMATIVE] ==== The <> of a <> may limit the number of -concurrent TCP connections from an individual <> to its hosted services to ensure availability and -responsiveness of its <>. +concurrent TCP connections from an individual <> to its hosted services. ==== [NOTE] @@ -30,7 +29,7 @@ allow unlimited connections, based on its resource capabilities and design goals ** <> and/or, ** `[source endpoint]` message property (see <>) and/or, ** client credentials used for TLS authentication. -* Securing the connection may be the most expensive part of an operation, so a <> may +* Securing the connection may be the most expensive part of an SDC service operation, so a <> may drop concurrent connections from a <> that exceed its limits, or respond with HTTP status code `429 (Too Many Requests)` (after securing the connection) to signal the <> to reduce its connection count and/or frequency.