| > It's possible that some multihomed sites will have to assign 4 or even 
| > more ip addresses per host, depend on what kind of ISPs they multihoming 
| > with. E.g. a site that happen to multihome to two tier-2 ISPs, each 
| > multihomed with two different tier-1 ISPs, each host in this multihomed
| > site will have 4 IP addresses in order to get full benefit of redundancy. 
| > One can image even more complicated case.
|
| I believe that it should be fairly straightforward to extend
| implementations to deal with this case; some of the proposals floating
| about actually significantly simplify the API's used by real
| applications.

Great, so an end-system with multiple IP addresses has to be able
to figure out:

        -- when one of the addresses is invalid for a particular 
           destination (or set of destinations) because of a partition
           somewhere in the Internet
        -- which of the addresses to use to talk to which address
           presented by a DNS AAAA query that coughs up a number of
           addresses for another end-system it wants to connect to

Christian Huitema's brute force system suddenly looks less
attractive: instead of a singly-numbered host sending out n packets
towards a destination with n addresses, we would instead do an m-numbered
host sending out n packets from each of the m addresses.   Whee.
This would make T/TCP *lots* of fun to use.

Then, assuming one kept the state necessary to handle the best
(or even first) SYN-ACK and abort all the non-best (or subsequent)
SYN-ACKs, there is the problem that the ES is now not well equipped
to deal with partitions or topology changes that make the connection
inefficient.   That is, when we have chosen the best (FSVO best)
source/destination address combination, and suddenly have that
pair not work, there is no mechanism in place to choose a new
source/destination pair, because we've inherited the non-survivability
during renumbering problem from IPv4.

In any event, when the network is hiccoughing, tossing a number
of non-flow-controlled packets to choose a new source/destination
pair from n*m - 1 combinations into it is probably a really bad idea.

        Sean.

Reply via email to