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

Re: yesterday

Iljitsch van Beijnum wrote:
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.
Agreed. I think that putting all the informations in the end-hosts would imply an unacceptable
waste of resources. Moreover, to best take advantage from the BGP routing system, we should
get access not to only one BGP table but to _all_ the BGP tables of the providers. This is
clearly unacceptable to put in all the end hosts.


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:
Of course. NAROS is not limited to just looking at BGP. It can monitor the exit links, check their
correct utilization, and change accordingly the way it proposes the best addresses.

- 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.
The 300s lifetime was just an example. We performed simulations that show that this
timeout is reasonable to get good traffic engineering capabilities for a site with ~7500 hosts
without putting to much load on the NAROS server (its load average was ~35 req/s).
Of course this does not mean that this timeout is always the best one. This is always a
trade-off between the server load and the traffic engineering quality.
Maybe the use of a multicast message to invalidate the cache would be useful. I'm
open to any suggestion. But remember that the detection of connectivity loss can also be
detected by the end-host, and probably faster than by the NAROS server. The goal
of the lifetime is only to reduce the number of NAROS requests to send. Just think
about a host that loads an web page : the host will probably open several connections
in a short period. Without lifetimes, the NAROS load would be rapidly unacceptable.

- 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.
Hehe, we already thought about this kind of stuff. NAROS means : _NAME_ Address and
ROute Server. This is an optimization but it would be interesting to go that way.

- 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.
This sounds good for me.
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.
Agree. This proposition is far to young to be standardized and needs to be stronger/bigger.
Some of our ideas were not written in the draft in order to make this proposition as open
as possible. I'm happy that Iljitsch come to the same conclusions and ideas than me.

Cédric