That's why I think it makes more sense to backport the SCTP multihoming
features to TCP so all TCP apps can use them without having to be
changed, or even better: contain the changes in a separate shim layer
so that all transport protocols can become address agile without having
to be changed.
TCP maintains congestion control
information about a single destination, with the assumption that the path
will not change during the connection. If it does occasionally, then it's
fine. However, with multihoming, the change may be a common occurance
throughtout the lifetime of a connection depending on the application and
the use of the multiple paths (failover, concurrent multipath transfer,
etc). So TCP (or whatever transport) should not be blind to the fact that
data is potentially going over a different path. Otherwise, the congestion
control parameters/algorithms will not work properly.
I don't think path changes are _that_ common with multihoming, either today or with a new protocol. In my ODT draft path changes only occur when the primary path fails in the first place, as this way the session can be compatible with regular TCP (or other upper layer protocol) if there are no failures.
Also, since the transport is maintaining per path information, it is in
the best decision to decide which path to use. Yes, a shim layer could
cooperate with the transport to get this info, but then you are changing
TCP anyway.
I see three steps in the evolution of a shim approach:
1. Implementation in proxy multihoming boxes 2. Implementation as a shim layer in host stacks 3. Integration of the shim layer and common transport protocols
The idea is that a type 1 implementation can work together with a type 2 or 3 implementation.
I must admit that I haven't following the multi6 too closely yet, but I
plan to catch up and follow. But from what I have seen, it seems that SCTP
is ignored on the sidelines.
Actually the chairs went out of their way to get an SCTP multihoming draft in before the deadline. The deadline for submitting drafts that would be considered has recently passed, so now is a good time to read the drafts and join the architectural analysis that should be starting shortly.