[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: IETF multihoming powder: just add IPv6 and stir

On woensdag, mei 14, 2003, at 14:52 Europe/Amsterdam, Michael H. Lambert wrote:

Second, why use fifth hand information if a host can simply
send some packets and see if they make it through? That's much more
effective and light-weight at the expense of some only a few otherwise
unnecessary end-to-end packets. Routing protocols seldom know which paths
are good. They barely know how to avoid the very bad and non-functioning
ones.


Just because the path is valid (and perhaps "good" by a reasonable set 
of metrics) does not mean that it is even near-optimal.  A host 
sending a few packets to check a path will have no idea of the 
bandwidth along the path, for example.



Note that in the commodity internet the bandwidth of a path is a 
non-issue: ISP connections are almost always of a much higher bandwidth 
than the part between the ISP edge and the end-host.



I agree that a few packets isn't enough to determine the bandwidth of a 
path but with a higher number of packets this shouldn't be much of a 
problem. But in these cases a partial routing table in the host would 
be ok, I guess.



Another approach is to use diffserv to signal packets should take the 
high-bandwidth path.




The solutions should be end to end that complex functionality must
be performed only on hosts.





I agree in principle. However, if we can give people the option to
offload this to a middlebox if they so desire, that's a plus.





I think the right approach is to allow the functionality to be 
implemented hierarchically.


What does that mean?




I think the right way to think about this is that whatever device is 
responsible for making decisions about dynamic source address 
selection can usually benefit from hints from the routing protocols.



I'm not saying there are no benefits, just that the downsides are much 
bigger and that it would be unacceptable to mandate having a routing 
table in each host.




In fact, we need to go even further and implement functionality in
neighbor discovery to enable the use of jumboframes between two hosts
that support them even though other hosts on the same subnet may not.





Exactly, although probably not important for small flows (< 100 Mb/s).




I don't think setting the MTU based on the flow speed is useful: either 
you can do it so you do it or you can't so you don't. But I agree there 
isn't much point in having jumboframes in 10 or 100 Mbps equipment and 
it seems vendors feel the same way because I have yet to encounter a < 
1000 Mbps ethernet NIC that supports them.