> 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 agree. But, as you mention in an other mail, TCP/SCTP/DCCP has a limit to do simultaneous tranfer. It is impossible to provide concurrent multipath transfer without changing the cc algorithms. But, given current options, transport is the better judge to do zero click fail-over. > Also, since the transport is maintaining per path information, it is in > the best decision to decide which path to use. *nod*. It is the main reason why multi addressing is the only architectural possibility to do a scalable MH. The problem with the remaining solutions (at shim/new identity/network layer) is that they hide the redundancy factor (multiple address -MA) from the users. Given the current state (failures, misconfigurations and rate limitations,) e2e check (by measurements) is the only option to check path availability. The MA feature gives user a chance to make a choice based on e2e reachability checks. I dont know why people get suprised by explicit announcement of MA. we have been doing this kind of explicit announcement both in DNS ( multiple NX records) and SMTP ( multiple MX records.) So, in a way SMTP reliability is due to explicit announcement of multiple MX records. id/loc split proposals are cool. But, without modifying the routing architecture, they can never provide a e2e reliability or explicit user control feature. OTOH, I don't forsee any routing change at *architectural* level in the near future. It is time to think on why id/loc split proposals without routing architecture change kill the e2e control/reliability options and are architecturally incomplete. So, it is clear that a combination/subset of host-centric MH, transport MA and BGP MH (if there exists a solution which doesn't bloat routing table) is the ONLY possibility to do a scalable MHv6.