Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Explain stacked layers of keep alive protocols #1452

Merged
merged 2 commits into from Nov 9, 2023
Merged

Explain stacked layers of keep alive protocols #1452

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
256ac98
Explain stacked layers of keep alive protocols
tfpauly Nov 9, 2023
cd157eb
Update draft-ietf-taps-impl.md
tfpauly Nov 9, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
11 changes: 10 additions & 1 deletion draft-ietf-taps-impl.md
View file
Open in desktop
Expand Up @@ -776,9 +776,18 @@ Connection Properties. A Connection can also generate error events in the form o

The set of Connection Properties that are supported for setting and getting on a Connection are described in {{I-D.ietf-taps-interface}}. For
any properties that are generic, and thus could apply to all protocols being used by a Connection, the Transport Services implementation should store the properties
in storage common to all protocols, and notify all protocol instances in the Protocol Stack whenever the properties have been modified by the application. {{!RFC8303}} and {{!RFC8304}} offer guidance on how to do this for TCP, MPTCP, SCTP, UDP and UDP-Lite; see {{specific-protocol-considerations}} for a description of a back-tracking method to find the relevant protocol primitives using these documents.
in storage common to all protocols, and notify the Protocol Stack as a whole whenever the properties have been modified by the application. {{!RFC8303}} and {{!RFC8304}} offer guidance on how to do this for TCP, MPTCP, SCTP, UDP and UDP-Lite; see {{specific-protocol-considerations}} for a description of a back-tracking method to find the relevant protocol primitives using these documents.
For Protocol-specific Properties, such as the User Timeout that applies to TCP, the Transport Services implementation only needs to update the relevant protocol instance.

Some Connection Properties might apply to multiple protocols within a Protocol Stack. Depending on the specific property,
it might be appropriate to apply the property across multiple protocols simultaneously, or else only apply it to one protocol.
In general, the Transport Services implementation should allow the protocol closest to the application to interpret
Connection Properties, and potentially modify the set of Connection Properties passed down to the next protocol in the
stack. For example, if the application has requested to use keepalives with the `keepAlive` property, and the Protocol
Stack contains both HTTP/2 and TCP, the HTTP/2 protocol can choose to enable its own keepalives to satisfy the application
request, and disable TCP-level keepalives. For cases where the application needs to have fine-grained per-protocol control,
the Transport Services implementation can expose Protocol-specific Properties.

If an error is encountered in setting a property (for example, if the application tries to set a TCP-specific property on a Connection that is
not using TCP), the action must fail gracefully. The application must be informed of the error, but the Connection itself must not be terminated.

Expand Down