Subject: yesterday

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 15 Jul 2003 10:18:33 +0200

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.

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Tue, 15 Jul 2003 10:39:51 +0200

> Some random thoughts on the session yesterday:

Wait! This is what we are supposed to do tomorrow! :-)

> available. This is something we absolutely can't have with 
> multihoming, in my not so humble opinion.

I think this brings up the issues from the IAB meeting yesterday, what 
do we want to change when. That we need to change large parts at some 
point, I think is clear. Question is if this will really influence IPv6 
adoption or not (if the change takes us 10+ years - after we have 
consensus, is it really an issue). And what we do in the mean time. It 
will be interesting to see what the IAB comes up with.

I personally think that Brians presentation from yesterdays IAB meeting 
was very good and pointed to the problems. And the problems with the 
solutions.

- - kurtis -

---

From: Tim Chown <[email-masked]>
Date: Tue, 15 Jul 2003 09:44:36 +0100

Hi,

I think an important message we saw from the multi6 session was that we can
do a great deal now for small/medium networks, including the interesting
SOHO case, with Christian's approach.   This is well-grounded practical
technology that we can work on, trial and use now.   The more feedback we
get on this from real deployment, the better :)

I agree NAROS++ could help add to Christian's proposal for sites that may
wish to manage their host-based policy (as Craig has requested in the past).
It is perhaps a distraction though for Christian's basic proposal, which
can probably fly as it stands.

In the short term it appears we need to meet demand for multihoming in "large"
enterprises by bending the allocation rules, for /48's or /32's, such that
big enterprises may get a SubTLA or /48.   However it is not clear what sort 
of demand there is out there right now for this, and thus how big a swamp
we would create.  
[Regarding the ASN method to allocate prefixes, could we simply state that 
only networks with ASNs as of <insert date less than today> qualify?]

In the longer term the identity-location split appears most interesting.  We
have some good proposals in that area, e.g. from HIP and Pekka N's work.   

Perhaps we should think about multi6 rechartering to match whatever general
path we wish to take?   But that's the discussion for Wednesday morning :)

Thanks to Kurtis for a nicely chaired meeting.

Tim

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 15 Jul 2003 10:59:14 +0200

On dinsdag, jul 15, 2003, at 10:39 Europe/Amsterdam, Kurt Erik 

> do we want to change when.

Ok, my position is: we don't want to change the API right here, right 
now. The cost/benefit ratio for doing this just for multihoming is out 
of whack. Don't forget that if the multihoming solution we come up with 
isn't attractive enough, people will simply push for PI in IPv6.

> That we need to change large parts at some

> was very good and pointed to the problems. And the problems with the

Yes, this was a quite disheartening list. Is it online somewhere, BTW?

I think what we need is a complete overhaul of the IP architecture. We 
are doing so many things that go completely against the original IP 
assumptions, that it is amazing IP keeps working to a useful level at 
all. And the socket API is high on the list of stuff that's ready for 
retirement. But this is much more fundamental than adding multihoming 
to IPv6, even though that problem is somewhat fundamental also.

---

From: Cedric de Launois <[email-masked]>
Date: Tue, 15 Jul 2003 11:23:22 +0200

Iljitsch van Beijnum wrote:

> 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.

> utilization for different connections and do traffic engineering. Some 

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.

> 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.

> 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.

> 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

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 15 Jul 2003 11:27:44 +0200

...
> Yes, this was a quite disheartening list. Is it online somewhere, BTW?

It will show up in due course somewhere. If anyone has a handy server,
I will supply a PDF.

   Brian

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Tue, 15 Jul 2003 11:52:52 +0200

> It will show up in due course somewhere. If anyone has a handy server,

I will create a web-page for the multi6 presentations, I can put it 
there if you want to.

Best regards,

- - kurtis -

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 15 Jul 2003 23:56:13 +0859 ()

Tim;

> SOHO case, with Christian's approach.

As we discussed, Christian's approach works for a single link network,
but not beyond.

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 15 Jul 2003 23:52:57 +0859 ()

Iljitsch;

> problems with this,

I'm afraid you completely misunderstand the routng architecture.

> I'm almost certain we need to create more or less a 

Hugh? Read the draft. It says:

   Note that end to end multihoming works with the separation between
   inter domain BGP and intra domain routing protocols, if BGP routers,
   based on local policy of the domain, assign external routes
   preference values (metric) of intra domain routing protocols.

> 60 MB, a third of which is kernel memory wich can't be swapped out). 

Are you saying v6 routing table should bloat like that of v4 that
multi6 should disband?

> aggregated away in the global routing table,

The goal of multi6 goal is to aggregate the global routing table.

A good news is that there is no good stuff to be lost.

> so the info you can derive 

As I said yesterday TCP is not IP. The Internet is connectionless.

Moreover, even TCP needs initial guess which address to use.

						Masataka Ohta

---

From: Tim Chown <[email-masked]>
Date: Tue, 15 Jul 2003 16:14:29 +0100

> As we discussed, Christian's approach works for a single link network,

That's your opinion :)

It would be good to get more experience "in the field" seeing how far we
can go with the existing toolbox, and what compromises we make in doing so.
In that respect Christian's initiative is good for probing many areas.

Tim

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 16 Jul 2003 00:15:29 +0859 ()

Cedric;

As I have been documenting that:

  One may still be allowed, though discouraged, to have local
  configuration with dumb end systems and an intelligent proxy. But,
  such configuration should be implemented with a protocol for purely
  local use without damaging the global protocol.

having proxies for really dumb hosts is discouraged but not prohibitted.

But, do it locally.

> clearly unacceptable to put in all the end hosts.

That is clearly unacceptable, though it has nothing to do with my
proposal.

So?

> correct utilization, and change accordingly the way it proposes the best 

That's a job already done by the routing system.

We know very well that having a central server for routing
job is a bad idea. Let the job done by routers.

> in a short period. Without lifetimes, the NAROS load would be rapidly 

That is one reason against proxies, but there are a lot more.

> trade-off between the server load and the traffic engineering quality.

No. Proper timeout is determined by applications.

							Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 16 Jul 2003 00:30:08 +0859 ()

Tim;

> > As we discussed, Christian's approach works for a single link network,

Not mine.

We know PMTUD does not always work and you can't stop hosts just
sending 1280B packet to a path MTU of which is 1280.

							Masataka Ohta