From 22ad6e6116a10d6fc3f1ce082e4e64b0e1512733 Mon Sep 17 00:00:00 2001 From: mirjak Date: Wed, 5 Aug 2020 13:46:49 +0200 Subject: [PATCH 1/5] Edits on Section on Handling Path Changes This is a first attempt to work on the section "Handling Path Changes" (see issue #545), however, I think more work is needed. To be honest I don't fully understand this part and it would be could if someone else could provide more input about the System Policy part: "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." Also the last part about pooled connection should say more but I'm not sure what. We currently have now only this sentence left: "Pooled Connections {{pooled-connections}} may add or remove underlying transport connections in a similar manner." And finally the originally issue #545 was also mentioning fallback which I didn't address yet but I have this feeling that that might need a separate section. Should I add a separate issue for that or is that already addressed somewhere and I missed it? --- draft-ietf-taps-impl.md | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/draft-ietf-taps-impl.md b/draft-ietf-taps-impl.md index 8db99c45..7cf58632 100755 --- a/draft-ietf-taps-impl.md +++ b/draft-ietf-taps-impl.md @@ -722,8 +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 in order to quickly react to path failures before a time-out occurs. + +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. + +If the Protocol Stack includes a transport protocol that supports multipath connectivity also in form of migration support, the Transport Servics implementation should also inform the Protocol Instance of potentially new paths that are permissible based on the Selection Properties passed by the application. A protocol can establish new subflows over new paths as long as an active path is still available or, if migration is supported, also after the break has been detected, and should attempt 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. Further the decision when to create a new path or announce a new path or set of paths to the other end, e.g. in form of additional IP addresses, is implementation specific or maybe be supported by future API extensions. 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 for migrating the connection. + +Pooled Connections {{pooled-connections}} may add or remove underlying transport connections in a similar manner. From fc3b249265353a9b43858e0dc4ebb7abb31508bb Mon Sep 17 00:00:00 2001 From: Gorry Fairhurst Date: Wed, 12 Aug 2020 10:53:50 +0100 Subject: [PATCH 2/5] Update draft-ietf-taps-impl.md Edits to improve reading. --- draft-ietf-taps-impl.md | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/draft-ietf-taps-impl.md b/draft-ietf-taps-impl.md index 7cf58632..0503ca1e 100755 --- a/draft-ietf-taps-impl.md +++ b/draft-ietf-taps-impl.md @@ -722,16 +722,15 @@ This enables implementations to realize transparent connection coalescing, conne ## Handling Path Changes -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 in order to quickly react to path failures before a time-out occurs. +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. 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. -If the Protocol Stack includes a transport protocol that supports multipath connectivity also in form of migration support, the Transport Servics implementation should also inform the Protocol Instance of potentially new paths that are permissible based on the Selection Properties passed by the application. A protocol can establish new subflows over new paths as long as an active path is still available or, if migration is supported, also after the break has been detected, and should attempt 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. Further the decision when to create a new path or announce a new path or set of paths to the other end, e.g. in form of additional IP addresses, is implementation specific or maybe be supported by future API extensions. 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 for migrating the connection. +If the Protocol Stack includes a transport protocol that supports multipath connectivity also in form of migration support, the Transport Services implementation should also inform the Protocol Instance of potentially new paths that are permissible based on the Selection Properties passed by the application. A protocol can establish new subflows over new paths while an active path is still available or, if migration is supported, also after the 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 migrating the connection. Pooled Connections {{pooled-connections}} may add or remove underlying transport connections in a similar manner. - # Implementing Connection Termination With TCP, when an application closes a connection, this From 92ae963e355af5151f9424bcd6b9a897b1845e42 Mon Sep 17 00:00:00 2001 From: Gorry Fairhurst Date: Wed, 12 Aug 2020 10:56:59 +0100 Subject: [PATCH 3/5] Update draft-ietf-taps-impl.md More improvements. --- draft-ietf-taps-impl.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-taps-impl.md b/draft-ietf-taps-impl.md index 0503ca1e..db3514c8 100755 --- a/draft-ietf-taps-impl.md +++ b/draft-ietf-taps-impl.md @@ -726,7 +726,7 @@ When a path change occurs, e.g. when the IP address of an interface changes, thi 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. -If the Protocol Stack includes a transport protocol that supports multipath connectivity also in form of migration support, the Transport Services implementation should also inform the Protocol Instance of potentially new paths that are permissible based on the Selection Properties passed by the application. A protocol can establish new subflows over new paths while an active path is still available or, if migration is supported, also after the 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 migrating the connection. +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. Pooled Connections {{pooled-connections}} may add or remove underlying transport connections in a similar manner. From ee5347dd3987ce8ffcca344e0d2dab018a364f6c Mon Sep 17 00:00:00 2001 From: mirjak Date: Wed, 2 Sep 2020 19:27:21 +0200 Subject: [PATCH 4/5] Update draft-ietf-taps-impl.md Co-authored-by: Philipp S. Tiesel --- draft-ietf-taps-impl.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-taps-impl.md b/draft-ietf-taps-impl.md index db3514c8..f1df2975 100755 --- a/draft-ietf-taps-impl.md +++ b/draft-ietf-taps-impl.md @@ -728,7 +728,7 @@ For protocols that do not support multipath or migration, the Protocol Instances 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. -Pooled Connections {{pooled-connections}} may add or remove underlying transport connections in a similar manner. +In case of Pooled Connections {{pooled-connections}}, the transport system may add connections over new paths or different protocols to the pool if permissible based on the multipath policy and Selection Properties. In case a previously used path becomes unavailable, the transport system may disconnect all connections that require this path, but should not disconnect the pooled connection object exposed to the application. The strategy how is implementation specific, but should me consistent with the behaviour of multipath transports. # Implementing Connection Termination From 0341888f062877b8ab97957e6d52977c461593db Mon Sep 17 00:00:00 2001 From: Tommy Pauly Date: Fri, 23 Oct 2020 08:38:00 -0700 Subject: [PATCH 5/5] Apply suggestions from code review --- draft-ietf-taps-impl.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/draft-ietf-taps-impl.md b/draft-ietf-taps-impl.md index f1df2975..f12e8f5b 100755 --- a/draft-ietf-taps-impl.md +++ b/draft-ietf-taps-impl.md @@ -722,13 +722,13 @@ This enables implementations to realize transparent connection coalescing, conne ## Handling Path Changes -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. +When a path change occurs, e.g., when the IP address of an interface changes or a new interface becomes available, the Transport Services implementation is responsible for notifying the application of the change. The path change may interrupt connectivity on a path for an active connection or provide an opportunity for a transport that supports multipath or migration to adapt to the new paths. -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. +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. -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. +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 Transport Services 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. -In case of Pooled Connections {{pooled-connections}}, the transport system may add connections over new paths or different protocols to the pool if permissible based on the multipath policy and Selection Properties. In case a previously used path becomes unavailable, the transport system may disconnect all connections that require this path, but should not disconnect the pooled connection object exposed to the application. The strategy how is implementation specific, but should me consistent with the behaviour of multipath transports. +In case of Pooled Connections {{pooled-connections}}, the transport system may add connections over new paths or different protocols to the pool if permissible based on the multipath policy and Selection Properties. In case a previously used path becomes unavailable, the transport system may disconnect all connections that require this path, but should not disconnect the pooled connection object exposed to the application. The strategy how is implementation-specific, but should be consistent with the behavior of multipath transports. # Implementing Connection Termination