RE: Multihoming by IP Layer Address Rewriting (MILAR)

["Christian Huitema" <huitema@windows.microsoft.com>]

> From: RJ Atkinson [mailto:rja@inet.org]
> At 15:16 04/09/01, Christian Huitema wrote:
> >Game stations, and PC running video-games, obtain
> >incoming connectivity by registering their address in a game lobby.
> 
> Christian,
> 
>         A few special cases != generally.

We are not speaking of a few special cases here. Game players are in the
tens of millions, at least. Last time I looked at the IM market, there
were at least 150 million users. Many of us hope to see Internet
telephony grow to the size of the existing telephone network. Napster
had at one point 70 million users... I will grant you that the vast
majority of web servers can be reached on the DNS. But that is
definitely not a reason to build a dependency between IP and the DNS. I
want to support game users, I want to let then multi-home between DSL
and Cable.

There is also a practicality issue. The current DNS practice would hit
any DNS based scheme in multiple ways: many reverse (PTR) entries, and
in fact many direct (A, AAAA) entries are "pro-forma", such as
"64-5-6-7.example.net"; many server entries use multiple A records for
load balancing, with addresses pointing at different servers. You will
get maximum confusion if you try to use the existing data for
multi-homing.

Then, there is a performance issue. Last time I checked, about 25% of
DNS queries took more than 3 seconds to complete. In fact, if you look
at http://www.netsizer.com/daily/quality_today.html, you observe that at
least 5% of queries for the addresses of large servers don't complete in
less than 3 seconds, and that 5% of queries for the addresses of small
servers don't complete in less than 6 seconds! I don't believe that
adding more load to the DNS is a good idea, when the infrastructure is
so obviously strained.

There is an obvious alternative to DNS discovery of peer addresses,
which is, have the peer tell you. We obviously have to wrestle with the
security implications, but there have to be solutions -- nonce, s-key,
self signed certificates, etc. We don't need to throw a server in the
mix.

-- Christian Huitema