Re: Ohta-san's draft

[Erik Nordmark <Erik.Nordmark@eng.sun.com>]

> Then bear in mind that this split allows for an important
> optimization: if the hosts DO care about all the bits, and
> given that real Internet traffic is often forwarded on
> asymmetric paths, and thus (and for other reasons)
> failures may be simplex, then there are NxM combinations
> of (source,destination) that must be agreed upon to have a
> connection.  Using Ohta's method, since it cares only
> about the *sender*'s choices, there are only N or M where
> N and M are the number of addresses each host believes
> can be used to reach the other.
> 
> That is, no "who"/"what" split: NxM.  With "who"/"what" split: Nx1.
> Because we don't have to do anything special with choosing
> a working/optimal source address.

That might be true once you have established the sessions.
However, in order to establish sessions I think there are two
choices:
 - initiator includes a list of its addresses to the peer
 - the initiator includes just its identity (e.g. a DNS name) 
   which the responder uses to determine its addresses.

The second choice is a DoS attackers dream - a TCP SYN making the receiver
do a DNS lookup or something of similar nature.
The first choice requires at a minimum that the initiator knows all its
addresses. When one of those addresses doesn't work either the initiator
can retransmit (listing the addresses in different order) or the
responder needs to try all the addresses.
It the initiator is responsible for retransmitting the session establishment
packet (SYN for TCP) than its end up trying NxM.
If the initiator is responsible for trying all destination addresses
(M) and the responder will try all included addresses (N) then
you have less choices to search, but there are some difficult
issues due to the lack of coordination between the two ends.
It definitely makes sense exploring this space further.

In the case of two addresses for each end (A1, A2, B1, B2) and TCP (so
I can label the packets SYN and SYN|ACK) it could look like this:

1. A1	SYN 	->	B1	Packet received
2.    x	SYN|ACK	<-	B1	Packet dropped - A1 not reachable
3. A1	SYN	->	B2	A tries second address for B
4. A2	SYN|ACK	<-	B1	B tries second address for A

In the above case with A1 not being reachable the 3rd packet is unnecessary.
But perhaps that isn't a big deal.

   Erik