diff --git a/CHANGELOG.md b/CHANGELOG.md index 3da5a619..34e7d838 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -25,6 +25,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 endpoint address that can be used to communicate with a <>. +| A physical 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..0370914c --- /dev/null +++ b/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 <> 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 help mitigate risks to the 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. +==== + +[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 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. +==== + +// 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 1b48ac1c..7f8ee6b8 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[]