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

Edits on Section on Handling Path Changes #614

Merged
merged 5 commits into from Oct 23, 2020
Merged

Edits on Section on Handling Path Changes #614

Changes from 3 commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
22ad6e6
Edits on Section on Handling Path Changes
mirjak Aug 5, 2020
fc3b249
Update draft-ietf-taps-impl.md
gorryfair Aug 12, 2020
92ae963
Update draft-ietf-taps-impl.md
gorryfair Aug 12, 2020
ee5347d
Update draft-ietf-taps-impl.md
mirjak Sep 2, 2020
0341888
Apply suggestions from code review
tfpauly Oct 23, 2020
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
8 changes: 6 additions & 2 deletions draft-ietf-taps-impl.md
View file
Open in desktop
Expand Up @@ -722,9 +722,13 @@ This enables implementations to realize transparent connection coalescing, conne

## Handling Path Changes

When a path change occurs, the Transport Services implementation is responsible for notifying Protocol Instances in the Protocol Stack.
If the Protocol Stack includes a transport protocol that supports multipath connectivity, an update to the available paths should inform the Protocol Instance of the new set of paths that are permissible based on the Selection Properties passed by the application. A multipath protocol can establish new subflows over new paths, and should tear down subflows over paths that are no longer available. Pooled Connections {{pooled-connections}} may add or remove underlying transport connections in a similar manner. If the Protocol Stack includes a transport protocol that does not support multipath, but support migrating between paths, the update to available paths can be used as the trigger to migrating the connection. For protocols that do not support multipath or migration, the Protocol Instances may be informed of the path change, but should not be forcibly disconnected if the previously used path becomes unavailable. An exception to this case is if the System Policy changes to prohibit traffic from the Connection based on its properties, in which case the Protocol Stack should be disconnected.
When a path change occurs, e.g. when the IP address of an interface changes, this will usually break connectivity on that path for any active connection. Still, the Transport Services implementation is responsible for notifying Protocol Instances in the Protocol Stack if path changes are detected to enable them to quickly react to path failures before a time-out.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changing one IP address is a somewhat degenerate case—the more interesting case is a new interface/link coming up or down, and that's what drives more significant multipath and migration events. I also think that focusing first on the case that make break connectivity is not a great way to start out.

Copy link
Contributor Author

@mirjak mirjak Aug 14, 2020 •
edited

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was trying to separate this in the cases where a) the protocol does not support multipath migration in any more and b) where is does (however also realising that full multipath support like MPTCP and path migration ala QUIC is maybe not that similar). So for a) the only interesting event is to know that a path somehow is confirmed to be failed and therefore the protocol instance can decide to close the connection immediately rather than waiting for a time out, no?

Copy link
Contributor

@gorryfair gorryfair Oct 2, 2020 •
edited

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this is about interfaces that fail, and what happens after. ... SCTP-PR, MP-TCP, QUIC, etc. I'm unsure I see why this is important except in corner cases, isn't this action like a reset (from the local network layer)?
... but transports can also survive link up/down events, so not sure where this is heading?

tfpauly marked this conversation as resolved.
Show resolved Hide resolved

For protocols that do not support multipath or migration, the Protocol Instances should be informed of the path change, but should not be forcibly disconnected if the previously used path becomes unavailable. An exception to this case is if the System Policy changes to prohibit traffic from the Connection based on its properties, in which case the Protocol Stack should be disconnected.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is trying to explain the case where an address goes away due to an interface going down, but one shouldn't necessarily tear down the transport immediately. For example, if someone walks into an elevator, drops off of Wi-Fi, and then exits the elevator and comes back onto Wi-Fi, a non-migrating connection would do better to just wait for the network to come back, rather than tear down and interrupt a download.

Copy link
Contributor Author

@mirjak mirjak Aug 14, 2020 •
edited

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My question was more about when you should ever even try to "forcibly disconnect" rather the just let the connection/protocol instance decide to close the connection...? And what the relevant policy bit here?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree with Tommy - if the protocol implements fail-over in some way, then it can use this. Otherwise, the transport ought to treat this as a soft error. It should not alter its state (to disconnect) because this makes it think a part of the path might not work.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I also agree. I was asking if there every is a case where the protocol instance should be forcibly disconnect. If not we should rephrase this.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think if the case exists, it is likely a special design - or a function of a specific transport, in general I'd say leave the transport to make the correct action.

tfpauly marked this conversation as resolved.
Show resolved Hide resolved

If the Protocol Stack includes a transport protocol that also supports multipath connectivity with migration support, the Transport Services implementation should also inform the Protocol Instance of potentially new paths that become permissible based on the Selection Properties passed by the application. A protocol can then establish new subflows over new paths while an active path is still available or, if migration is supported, also after a break has been detected, and should attempt to tear down subflows over paths that are no longer used. The taps API provides an interface to set a multipath policy that indicates when and how different paths should be used. However, detailed handling of these policies is still implementation-specific. The decision about when to create a new path or to announce a new path or set of paths to the remote endpoint, e.g., in the form of additional IP addresses, is implementation-specific or could be be supported by future API extensions. If the Protocol Stack includes a transport protocol that does not support multipath, but does support migrating between paths, the update to the set of available paths can trigger the connection to be migrated.
tfpauly marked this conversation as resolved.
Show resolved Hide resolved

Pooled Connections {{pooled-connections}} may add or remove underlying transport connections in a similar manner.
mirjak marked this conversation as resolved.
Show resolved Hide resolved


# Implementing Connection Termination
Expand Down