Edits on Section on Handling Path Changes #614
Conversation
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?
|
II like your change - makes the text much clearer. |
Edits to improve reading.
More improvements.
draft-ietf-taps-impl.md
Outdated
| @@ -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. | |||
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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?
draft-ietf-taps-impl.md
Outdated
|
|
||
| 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. |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
Co-authored-by: Philipp S. Tiesel <philipp@tiesel.net>
|
@mirjak : Is the path change problem resolved here - there's been stuff added on paths and policy since this. |
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?