Re: mini-cores (was Re: ULA-C)

["Stephen Sprunk" <stephen at sprunk.org>]

Thus spake "Keith Moore" <moore at cs.utk.edu>
> > Well, a start would be a "connectbyname()" API call that takes
> > care of name-to-address mapping and trying different
> > addresses until one works.
>
> Most IPv6-capable apps seem to implement that logic now.  And
> in my experience, it sucks.  Really hard.   The app can take a
> very long time to establish a very poor connection.  The specific
> reason tends to be that the destination and source both have IPv4
> and IPv6 addresses, and the IPv4 address works better than the
> IPv6 address (maybe because of 6to4 relay routers or whatnot),
> even though the v6 address is chosen first.

Don't forget that you may have a half-dozen or more IPv6 PA addresses that 
_all_ have to be tried before the host is going to give up and try the v4 
address(es).  ULAs and LLAs also fit in there somewhere, as do 6to4 
addresses, Teredo addresses, VPN connections, etc.  Worse, the other host 
has just as many addresses as you do, with the same variable connectivity 
for each.  You can _easily_ end up with 100+ combinations to probe.

Murphy's Law says that the only address pair that works will be the last one 
that your "address selection" algorithm determines, no matter what algorithm 
you pick.  If you fix the algorithm, fate will respond by changing 
reachability so that the new "last" pair to probe is again the only one that 
works.

> But this is just an instance of the general case that some
> source-destination address pairs work better than others.
> Address selection heuristics don't do a good job solving this
> problem - to solve this problem the network actually needs to tell
> the host which source-destination address pairs will work well.
> (and that's pretty ugly)

Yes, it's ugly, and it's not the only solution.  Another is for the client 
to initiate connections from every possible source address to every possible 
destination address at the same time, and for the transport protocol to 
support adding and removing L3 addresses from the connection over its 
lifetime as each host gains/loses prefixes.  Good luck deciding which of the 
N*M paths to send payload packets over for optimal throughput, latency, 
reliability, and cost (among which the stack will likely have no indication 
of prioritization from the app).  And, of course, that'll entail a 
substantial rework of TCP and most TCP stacks, which means it's at least a 
decade away.  What are we supposed to do until then?

S

Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking 



_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www1.ietf.org/mailman/listinfo/ietf