503: concurrent consumer connections

CHANGELOG.md

@@ -25,6 +25,7 @@ Each section shall contain a list of action items of the following format: `<bri
 - Clarifying note to R7000 ([#501](https://github.com/IHE/DEV.SDPi/issues/501))
 - Clarifying statements to DEV-23, DEV-24, DEV-46, and DEV-47 w.r.t to ad-hoc and managed mode discovery([#409](https://github.com/IHE/DEV.SDPi/issues/409))
 - OID Framework to TF-3Z ([#474](https://github.com/IHE/DEV.SDPi/issues/474))
+- Clarify expected behaviour and requirements for consumers making multiple concurrent connections to providers ([#503](https://github.com/IHE/DEV.SDPi/issues/503)).
 - Distributed Alarm System option and related transactions DEV-48 and DEV-49 (a.k.a. early "pre-published" integration of the SDC A-PKP standard) ([#457](https://github.com/IHE/DEV.SDPi/issues/457))
 - Make restriction of xsd:durations to hours, minutes, seconds, and fractional seconds mandatory for all xsd:duration values ([#517](https://github.com/IHE/DEV.SDPi/issues/517))
 

asciidoc/volume0/tf0-ch-d-glossary.adoc

@@ -468,7 +468,7 @@ implements a service-oriented <<acronym_sdc>> architecture composed of service p
 |
 
 | [[term_transport_address, Transport Address]] Transport Address
-| A physical endpoint address that can be used to communicate with a <<vol1_spec_sdpi_p_actor_somds_provider>>.
+| A physical endpoint address that can be used to communicate with a <<vol1_spec_sdpi_p_actor_somds_provider>> or <<vol1_spec_sdpi_p_actor_somds_consumer>> .
 | XAddr
 |
 |

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

asciidoc/volume2/concurrent-connections/tf2-ch-a-mdpws-concurrent-connections.adoc

@@ -0,0 +1,137 @@
+[#vol2_ch_a_mdpws_concurrent_connections]
+==== MDPWS Concurrent Consumer Connections
+
+SDC allows a <<vol1_spec_sdpi_p_actor_somds_consumer>> to open multiple, concurrent TCP 
+connections to a <<vol1_spec_sdpi_p_actor_somds_provider>>'s hosted services.
+While this offers flexibility for implementations, <<vol1_spec_sdpi_p_actor_somds_provider>>
+may constrain the number of concurrent TCP connections to help mitigate risks to the availability of its 
+<<acronym_sfc,system function contribution>>.
+
+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 <<term_manufacturer>> of a <<vol1_spec_sdpi_p_actor_somds_provider>> may limit the number of 
+concurrent TCP connections from an individual <<vol1_spec_sdpi_p_actor_somds_consumer>> to its hosted services.
+====
+
+[NOTE]
+====
+* A <<vol1_spec_sdpi_p_actor_somds_consumer>> may choose to limit the number of concurrent connections 
+accepted from an individual <<vol1_spec_sdpi_p_actor_somds_consumer>> 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 <<vol1_spec_sdpi_p_actor_somds_consumer>> by its:
+** <<term_transport_address>> and/or,
+** `[source endpoint]` message property (see <<ref_oasis_ws_addressing_2006>>) and/or,
+** client credentials used for TLS authentication.
+* Securing the connection may be the most expensive part of an SDC service operation, so a <<vol1_spec_sdpi_p_actor_somds_provider>> may 
+drop concurrent connections from a <<vol1_spec_sdpi_p_actor_somds_consumer>> that exceed its limits, or respond with 
+HTTP status code `429 (Too Many Requests)` (after securing the connection) to signal the <<vol1_spec_sdpi_p_actor_somds_consumer>> 
+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 <<term_manufacturer>> of a <<vol1_spec_sdpi_p_actor_somds_consumer>> shall consider 
+the risks of opening multiple, concurrent connections to a <<vol1_spec_sdpi_p_actor_somds_provider>>'s 
+hosted services, including the potential impact on both the <<vol1_spec_sdpi_p_actor_somds_provider>>'s 
+and the <<vol1_spec_sdpi_p_actor_somds_consumer>>'s ability to deliver their respective 
+<<acronym_sfc,system function contribution>>.
+
+====
+
+[NOTE]
+====
+A consumer may choose to limit the number and/or frequency of concurrent connections it 
+opens to a <<vol1_spec_sdpi_p_actor_somds_provider>>'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 <<vol1_spec_sdpi_p_actor_somds_provider>>s 
+<<acronym_sfc,system function contribution>> including: hosted services (e.g., `GET` and subscription management),
+publishing updates, discovery and logging. 
+
+A <<vol1_spec_sdpi_p_actor_somds_consumer>> opening multiple concurrent connections to a 
+<<vol1_spec_sdpi_p_actor_somds_provider>>'s hosted services may consume a disproportionate number of 
+available connections, reducing the number of <<vol1_spec_sdpi_p_actor_somds_consumer>>s that a 
+<<vol1_spec_sdpi_p_actor_somds_provider>> can support and/or compromising its <<acronym_sfc,system function contribution>>.
+
+====== Consumer Rationale for Multiple Connections
+
+A <<vol1_spec_sdpi_p_actor_somds_consumer>> 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 <<vol1_spec_sdpi_p_actor_somds_provider>> experiencing excessive load:
+
+* may respond with HTTP status code `429` (Too Many Requests, <<ref_rfc_6585,RFC 6585, section 4>>), and 
+* may include a `Retry-After` header (<<ref_rfc_7231,RFC 7231, section 7.3.1>>) 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 <<vol1_spec_sdpi_p_actor_somds_consumer>> 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 <<vol1_spec_sdpi_p_actor_somds_provider>> includes the `Retry-After` header (<<ref_rfc_7231,RFC 7231, section 7.3.1>>) 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
+
+

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[]