Comment Multihoming and failover (Score 1) 233
Last time I looked seriously at SCTP (18 months ago), it had two "problems" with multi-homing and failover.
1) It only sends traffic over the current primary connection. Because the standby connection(s) are idle, it cannot detect failure on them until it needs to use them. On IP networks, failure takes a long time to detect. If the primary connection fails, it could switch to another failed (but not detected as failed) connection when there is a (better) working alternative.
2) It does not load-share. If there are three diverse routes, it makes sense to share the load over all three. This requires some metrics: Two broadband routes would loadshare, but in a broadband and ISDN backup case, the sharing would need to be uneven, or not at all (i.e. main+standby configuration).
Interestingly, providing 2 would solve 1.
Of course, these are problems introduced by the ability of SCTP to multi-home, it is not a regression on TCP (or UDP).
1) It only sends traffic over the current primary connection. Because the standby connection(s) are idle, it cannot detect failure on them until it needs to use them. On IP networks, failure takes a long time to detect. If the primary connection fails, it could switch to another failed (but not detected as failed) connection when there is a (better) working alternative.
2) It does not load-share. If there are three diverse routes, it makes sense to share the load over all three. This requires some metrics: Two broadband routes would loadshare, but in a broadband and ISDN backup case, the sharing would need to be uneven, or not at all (i.e. main+standby configuration).
Interestingly, providing 2 would solve 1.
Of course, these are problems introduced by the ability of SCTP to multi-home, it is not a regression on TCP (or UDP).
