comments on Host-Centric IPv6 Multihoming

[Coene Lode <Lode.Coene@siemens.atea.be>]

Dear Christian & Richard

A editorial nit first:
chapter 3.3 on page 5, paragraph below figure:
"...If the chosen exit router at Site X is RXB, the packet will flow freely
to RYC; if the chosen exit router at Site X is RYC, the response will also
flow freely.  ..."
The second "Site X" should be "Site Y", I think. Site X doesn't have a exit
router called RYC, but Site Y has.

On with the more serious stuff:

chapter 3.1 on page 4: Destination address selection
>
>The destination address selection let hosts select an address from the list
provided by names services such as the 
>DNS. Improving the address selection algorithm may result in address
choices that provide improved performances; 
>however, if the selected address is in fact unreachable, the host will
typically have to wait for a timer, notice the absence 
>of response, and try another address in the list. One may debate whether
this is better or worse than the current IPv4 
>solution, in which a domain may be temporarily unreachable while the
routing converges to a new state; in any case, a 
>solution that would not involve errors, delays and re-trials would be
preferable. An obvious improvement here would be to 
>make sure that the name servers to only list addresses that are reachable,
and are quickly updated when a change in the 
>site connectivity results in a change in the list of available addresses. 
>

Mmm, a third party that does know it better how things are going in the
network. To me a bit far fetched.
Imagine it being the DNS: depending on the TTL of the relevant information
and the place from where the query was launched, I wouldn't count on any
relialable info concerning the reachability of a host(let alone a network) ,
it would always be out of date. At least the transport would know it earlier
as its byte/msg stream is interrupted and it has the possibility to
changeover to another destination. If the transport layer would ask it to
DNS,... well not convinced DNS would do any better, more likely worse. And
then I forget that application ask something to DNS before they invoke the
transport layer. It would mean that the transport layer would have a direct
interface to DNS, not something that I am longing for.

I would certainly never count on the DNS for reachability information in any
solution(but that is my opinion)
Leave it to the transport layer to joggle with the destination addresses for
reachability.


chapter 3.2 on page 4: Source address selection
>
>Choosing the source address will affect the reverse path of the connection,
as the source address of the message will 
>become the destination address of the responses. This may be a serious
matter in asymmetric applications like web 
>access, in which the bulk of the data is sent by the server to the client.
If the multiple addresses correspond to different 
>ISPs, ideally the host would pick the source address that will provide the
best performance. As for destination address 
>selection, we may expect that the host will have some knowledge of the
effect of choosing one or the other address, for 
>example by observing that web pages are served faster through one address
than through the other. 
>
I agree with first sentence, that the selection of source address in the
initiating node will determine the reverse path .
The host could try to pick the best address but the only one on the host
that has a clear view on this would be the host's transport layer: (it knows
the addresses used within a association or all the TCP connections hurded
together towards its peer . I am not quite sure that the host network layer
would make sense out of it tryng to find the best performance.
It could also result in some sort of loadsharing across different paths(a
path is meant to be a certain source -destaination address tuple or also
know as a transport address) something that hasn't been researched very
much. In any case the transports layers presently used such as SCTP have
multiple paths but are are not allowed to loadshare across the paths in the
association and in case of TCP will have a single path for each of its
connections.

if loadinfo is contained in a third party(such as DNS) then things look even
more bad.

Conclusion: leave the DNS out of it, the (fill in your favourite
description) is alreay overloaded enough.

chapter 3.4 on page 5: Rapid reaction to topology changes
>
if the destination address selection is done by the transport, then no
objection over here. They got the tools to measure the "quality" of the
path. If others means are employed then all bets are off.

chapter 4.2 on page 7-8: Source address dependent routing
>
If I understand this correctly, then the exit router (be it a single one or
multiple) seems to have different paths to the same prefix avialable at the
same time. 
If that is the case, then that is like a open invitation to use those 2
paths at the same time. There might be a way to use those 2 (or more paths)
in the transport layer§be it TCP or SCTP) with some rules in the network for
selecting the links, so that the congestion control in the transport (TCP or
SCTP) won't go haywire. I am trying to figure this out, there might be a ID
out before Salt Lake city meeting on it. (It migth NOT fit all the
requirements of this WG but at least it is a worthwhile effort and might fit
the bill very nicely for some other folks)

There are still some weird things that are not clear to me, such as why is
the host routing the msg towards the router with the incorrect source
address prefix.....

Conclusion:
This clearly goes  in the right direction, especially if thirdparty stuff is
left out of it. Pity that it is only a edge based solution.

yours sincerly,
Lode Coene

Siemens atea ICN D CS D
Software development
Atealaan 34
B-2200   Herentals    Belgium
Tel: +32-14-2-52081   Fax: +32-14-2-53212
E-mail: lode.coene@siemens.atea.be