yesterday

[Iljitsch van Beijnum <iljitsch@muada.com>]

Some random thoughts on the session yesterday:

I once again want to object to the idea of putting a full routing table 
in each host, as suggested by Masataka Ohta. I see a lot of practical 
problems with this, I'm almost certain we need to create more or less a 
completely new protocol for this to work as the only protocol that has 
the right information is BGP but BGP needs manual configuration and 
that is NOT something you want to do for each host. Then there is the 
unnecessary resource consumption (IPv4 table using Zebra costs at least 
60 MB, a third of which is kernel memory wich can't be swapped out). 
But the more fundamental problem is that all the really good stuff is 
aggregated away in the global routing table, so the info you can derive 
from that is by far inferior to what you can get from talking to the 
other side. I don't mean _asking_ the other side, I mean doing 
measurements on the packets going back and forth, the same way TCP does 
to arrive at good round trip times.

Also, the NAROS approach gives nodes access to info in the routing 
table too without many of the drawbacks. Although I hope NAROS does 
more than just look at BGP or it has the same problem. But that 
shouldn't be a problem: a NAROS server could also look at the line 
utilization for different connections and do traffic engineering. Some 
other thoughts on NAROS:

- Timeouts are bad. They are always too long or too short. An 
additional way to handle invalidating caches in hosts would be to send 
out a multicast message for this. This way, the NAROS server can 
invalidate all caches and maybe even trigger rehoming of existing 
sessions when something significant happens to external connectivity.

- Probably controversial: why first do a name lookup and then a NAROS 
lookup? NAROS could be a superset of DNS so a host could ask the NAROS 
server for info on a FQDN and get everything it would normally get from 
a DNS server and then the address preference info. This is just an 
optimization of the lookup process, I'm not proposing any changes to 
the the DNS here.

- Hosts could send information they discover over the course of a 
session back to the NAROS server so that it can help other hosts. For 
instance, if a correspondent host has two addresses and the NAROS 
server doesn't have a strong feeling about which is better, and one 
doesn't work, the host sends back "this address didn't work" and then 
the server can lower the priority for this address so the next host 
will try the other address first.

I think NAROS has the potential to be a very powerful tool, which means 
it propably needs to be "bigger" than the author(s) originally 
anticipated. It would be a shame to standardize this in a way that soon 
becomes too constricting for what people actually want to do.

On the 16 bit AS == PI prefix thing: this is just plain a very bad 
idea. In the first place, it doesn't scale. Second, it WILL create a 
land rush as it's very easy to get an AS number (hi Michel). Third, 
current practice is already that the people with enough money that 
really want it can get their own prefix, so there is no need to 
specifically address this small group.

I did like a lot of the end-to-end, host centric and so on stuff, 
however, it seems to me that a lot of this doesn't include the latest 
wisdom on this subject. For instance, some form of 8+8 came up but 
there was no explanation about how this can work with 
autoconfiguration, how badly it breaks transport protocols and so on.

Also, some mechanisms (such as SCTP) need API changes. I think this is 
EXTREMELY dangerous as this is a huge stumbling block for IPv6 
adoption. The latest OSes support IPv6 and getting a tunnel or 6to4 is 
fairly trivial, but we the reason why there is very little IPv6 
adoption is that the applications simply fail to use it when it's 
available. This is something we absolutely can't have with multihoming, 
in my not so humble opinion.