On Fri, Mar 01, 2002 at 09:03:46PM +1100, Geoff Huston wrote:
Obviously, as already pointed out, the restriction here is that the device
cannot support persistent state across location changes, but worse, as far
as I can tell, is that it is an approach that has poor scaling properties.
In order to operate correctly in a timely fashion the relevant parts of the
DNS now require very short TTLs. At that point many of the assumptions of
the scaleability of the DNS tend to be called into question. Is the gain
worth the potential scaling pain?
I hear you. However, there are other ways of keeping stable IP
addresses at a local level (i.e., using switches, or even the
blatcherous VLAN technology). So if for example, the terminal room
staff at Minneapolis has a large enough pool of DHCP addresses for
everyone, plus some kind of local switching/VLAN architecture so that
people who use the conference network, regardless of whether they are
on the wireless or wired network, always have the same IP addresses,
then it becomes possible to keep the TTL at a fairly reasonable level,
and still win.
In addition, we should ask ourselves what sort of workload assumptions
we are placing on the mobile device. If the mobile device is
appearing and disappearing on and off the network (due to the laptop
being off during lunch breaks, and battery/power limitations), and if
you consider other constraints (such as in the case of a GPRS device,
the ***obscenely*** high cost of network bandwidth), it seems very
unlikely that the mobile device is likely to be a primary server of a
DNS zone, a commonly accessed web server (with pubicized URL's), or
even an SMTP receiver, simply due to the cost and availability issues.
Hence, even if thunk-laptop.thunk.org has a short TTL (say, 300
seconds), it's not clear to me what a huge dent that would make in
DNS's scaleability properties. The rest of the RR's in my zone will
have a nice, high TTL, because I know they are going to be stable.
And the number of people who would actually be using
thunk-laptop.thunk.org will be small, so it won't be appearing in many
DNS servers' caches. (In practice, it will probably only be when I'm
asking someone to scp something from one laptop to another, or if I
set up a web server so someone can quickly look at something from my
laptop.)
Is this a general solution? No, obviously not. But it certainly has
the advantage that I can deploy it today, without needing to get my
ISP or anyone else involved (unless I care about updating the reverse
DNS mappings, of course --- but it sounds like that will be taken care
of at Minneapolis.)
As for claims that this doesn't solve the general problem, I wonder if
it's *necessary* to solve the general problem of someone who wishes to
suddenly and instaneously teleport some critical bit of internet
infrastructure (say www.telstra.net or ns.telstra.net) from Sidney to
Helsinki and expect it to work without needing any advance setup. Yet
it seems to me that this is the problem which Mobile IP is trying to
solve.
If we relax the constraints sufficiently, clearly DHCP + DNS Update is
sufficient. What's not entirely clear to me is whether there are
enough common scenarios, for which DHCP + DNS Update is not
sufficient, and for which something like the approach used by Mobile
IP would solve the problem in a cost-effective way, such that it's
worth it to deploy Mobile IP. It may very well be that there are. I
just don't know what they might be.
- Ted
P.S. I can think of some partial answers; for example, if there is
high-speed internet access in my hotel, and assuming it is reasonably
priced, I might want to use it in the morning before I go down to the
terminal room. Presumably the hotel will be using different IP
addresses than the IETF terminal room, so I'd need to use dynamic DNS
updates to update my IP addresses. Assuming that I use a TTL of say,
half an hour, then it would take at least that long before that cache
entry would expire, and so other hosts on the internet would take that
long before the DNS entry would expire from their cache and they would
try to contact my host. So if my laptop supposed to receive mail over
SMTP, then clearly mobile IP would be a better solution, since the DNS
TTL timeout wouldn't be an issue.
But wait a moment; if the laptop is frequently appearing and
disappearing off the network, I wouldn't want it to be an SMTP
receiver anyway, since that would simply cause my mail to be stalled
on mail queues all over the net, and there's no guarantee that the
intervening MTA's will choose to retry delivery during the time while
the laptop is on the network. So clearly, a pull mechanism using IMAP
is a much choice anyway, since as an IMAP client, the laptop doesn't
even need to update my DNS entry before it contacts my mail server,
and downloads my e-mail.
So it goes --- I can't think of a usage scenario where the benefits of
Mobile IP actually buys me anything, and there isn't some other way of
doing it which might be better/faster/cheaper.