503: concurrent consumer connections

[PaulMartinsen]

📑 Description

Not all providers can support many concurrent consumer connections while some consumers and/or providers may benefit from multiple concurrent connections to mitigate risks. This PR outlines an approach, leveraging the HTTP 429 status code, to support interoperability for both scenarios.

☑ Mandatory Tasks

The following aspects have been respected by the pull request assignee and at least one reviewer:

• Changelog update (necessity checked and entry added or not added respectively)
• Pull Request Assignee
• Reviewer

[PaulMartinsen]

Thanks for all your comments @alex-pe1 . I think I responded to them all. I'd be happy to do a teams video discussion if that would be helpful. 7pm here is 9pm in Germany right now so any time before your lunchtime could work for me.

I see this PR as fleshing out expectations for a fault condition, which might be a starting point for something more advanced. But even with more complex solutions we can still have faults.

[alex-pe1]

It's not clear to me what a consumer manufacturer really should/shall do here. Also I still think that the provider ensures that multiple connections from a consumer don't impose any risk on the provider.

Maybe the other way around it's better?
A SOMDS Participant shall ensure that multiple, concurrent connections to or from another SOMDS Participant do not have negative impact on their ability to deliver their own current system function contribution.

Note: This defines no restrictions to the participant ability to reject any connection attempt.

(this may be already implicitly covered in B-PKP '5.2 Intended interoperability' giving also the system owner some responsibility)

[PaulMartinsen]

Yes, I think this builds on the material in 10700, §5.2. From there I think participants would just have to declare in the documentation that 1 connection was allowed or 2 connections were used. This may create a high burden on the system owner to identify interoperability issues that might undermine SDC adoption but be resolvable by participants.

Hmm. Can we say "negative impacts" in requirements? I had a go at reframing around risks:

.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_participant>> shall 
consider the risks of opening multiple, concurrent connections 
to or from another <<vol1_spec_sdpi_p_actor_somds_participant>> on the 
<<term_manufacturer>>'s <<vol1_spec_sdpi_p_actor_somds_participant>>'s 
ability to deliver their <<acronym_sfc,system function contribution>>.

====

[NOTE]
====
* A <<vol1_spec_sdpi_p_actor_somds_consumer>> may create concurrent connections 
when it invokes operations on one or more of a <<vol1_spec_sdpi_p_actor_somds_provider>>'s
services at the same time. 

* This requirement does not replace any limitation imposed by other requirements, which
may limit the number of concurrent connections made by a <<vol1_spec_sdpi_p_actor_somds_participant>>
such as RefRequirement:R1001[]. 

* A <<vol1_spec_sdpi_p_actor_somds_participant>> may limit the number concurrent connections
and/or frequency of connections when it receives a response with HTTP status code 
`429` (Too Many Requests). 

* A <<vol1_spec_sdpi_p_actor_somds_consumer>> may limit the number of
active subscriptions or close connections with infrequent notifications. 

* A <<vol1_spec_sdpi_p_actor_somds_participant>> may reject any inbound
connection attempt. When, for example, its backlog of pending connection
attempts exceeds available capacity for new connections.

====

[alex-pe1]

I see B-BKP sometime has sometimes 'safe use', maybe here: '(safe) establishment of system functions... We are here only in process of trying to establish a connection or (part) of a SDC system.

[PaulMartinsen]

Yes; I think that wasn't clear. I made it clearer…

.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_participant>> 
shall consider the risk that another <<vol1_spec_sdpi_p_actor_somds_participant>> 
could reject (additional) concurrent connections when assessing the ability of the 
<<term_manufacturer>>'s <<vol1_spec_sdpi_p_actor_somds_participant>> to deliver 
its <<acronym_sfc,system function contribution>>.

====

[NOTE]
====
* A <<vol1_spec_sdpi_p_actor_somds_consumer>> may create concurrent connections 
when it invokes operations on one or more of a <<vol1_spec_sdpi_p_actor_somds_provider>>'s
services at the same time. 

* A concurrent connection means 2 or more active client connections create by the
<<term_manufacturer>>'s <<vol1_spec_sdpi_p_actor_somds_participant>> to one other
<<vol1_spec_sdpi_p_actor_somds_participant>>. This requirement does not apply to 
connections to different <<vol1_spec_sdpi_p_actor_somds_participant>>s.

* This requirement does not replace any limitation imposed by other requirements, which
may limit the number of concurrent connections made by a <<vol1_spec_sdpi_p_actor_somds_participant>>
such as RefRequirement:R1001[]. 

* A <<vol1_spec_sdpi_p_actor_somds_participant>> may limit the number concurrent connections
and/or frequency of connections when it receives a response with HTTP status code 
`429` (Too Many Requests). 

* A <<vol1_spec_sdpi_p_actor_somds_consumer>> may limit the number of
active subscriptions or close connections with infrequent notifications. 

* A <<vol1_spec_sdpi_p_actor_somds_participant>> may reject, with or without any 
response, any inbound connection attempt. For example, when its backlog of pending 
connection attempts exceeds available capacity for new connections.

====

****