Subject: Re: Distributed Directories, master/slave, MADHCP, ... not!

From: Charles Perkins <[email-masked]>
Date: Sun, 8 Mar 1998 08:06:17 -0800 (PST)

Chip,

> I don't usually disagree with you, but here I will.
>
> I've used AppleTalk and IP networks for many, many years,
> and AppleTalk wins hands-down in the "usability" category.

No disagreement yet.  In fact, Appletalk has inspired Service
Location Protocol and probably a number of other things.

> I'd be willing to pay a fair amount of bandwidth to
> get a network that "just works".
> 
> Hopefully we can do that in MANET _without_ paying a big
> bandwidth price, but if we have to choose, I'd vote
> for something that is a HELL OF A LOT EASIER to set up
> than a typical IP network.

I don't think we're in serious disagreement here, BUT ...

What if you were presented with the following choices:

1) A network with separately configured IP addresses that could
   reliably scale up to 10,000 nodes,

2) A network with dynamically configured IP addresses that could
   reliably scale up to 50 nodes, or

3) A network with dynamically configured IP addresses that could
   typically scale up to 10,000 nodes, but with occasional
   address conflicts that can occur at unpredictable times.

Of course, the answer depends upon requirements.  I am under
the impression that reliable scalability outranks dynamic
IP address assignment on the list of requirements.  If I'm
wrong, then you will be right in treating my protocol suggestions
with a lot of suspicion. 

What I suggest is that we handle the topology maintenance
separate from IP address assignment.  If it's done by using
IPv6 autoconfigured IP addresses carried over from previous
attachment to the Internet, great!  If it's done by using DHCPv4
configured addresses acquired while attached to the Internet,
still fine.  If it's done by some sort of super-hairy address
selection and reconciliation process during ad-hoc network
maintenance, then that's somebody else's project that I can't
worry about for now.  Alternatively, you can propose that
the network population _starts off_ fully connected, does the
address assignment, and only after that stage is network
partitioning possible.

> PS. And I think if we come up with a solution that implicitly
> requires anything to be configured by hand, we've not done
> a great job. (Here I'm motivated by the continuing woes of
> trying to get IP addresses, default routers, TTLs, DNS, etc,
> all straightened out for a network, not to mention trying to
> configure OSPF and BGP parameters. One can argue the merits
> of DHCP or PPP, but I prefer them over hand configuration!)

I don't think anyone would disagree that well-administered DHCP
is "better than" hand configuration.  Poorly administered DHCP
is probably worse than hand configuration.  I doubt that anyone
is seriously arguing the merits of hand configuration.  My note
was intended to suggest that we focus on topology maintenance
_separate_ from address assignment.  I really think it's the only
approach that makes sense in 1998.

Regards,
Charlie P.

---

From: Chip Elliott <[email-masked]>
Date: Mon, 09 Mar 1998 01:34:31 -0500

At 08:06 AM 3/8/98 -0800, Charles Perkins wrote:
>    (list of choices follows)

Charlie,

Well, I guess I'd take issue with the statement of the
choices. Can I rephrase those choices a little differently?

1. A network with 10,000 nodes that required careful & consistent
hand configuration of each node, because one little mistake
would mean that the routing protocols would fail mysteriously.
(For example, mistyping an IP address so we erroneously
had duplicates.)

2. A network that was truly "ad hoc", ie, could be
created out of any computers that happened to be lying
about, no matter how (badly) they had been configured
before they were brought onto the scene.

You bet I'd vote for #2. And of course so would you.

I would argue that the strawman #1 choice is "not scalable".
That is, the protocol design should make it EASY to have a
network come together properly, and this may include features
that check for duplicate IDs, or (better yet), rule out
those kinds of problems all together.

I do agree with your general wish to (a) keep it simple,
and (b) get part of the solution up and running. But I am
also afraid that the 30% solution might lead to endless
headaches later on. So I propose as a step going forward
that any draft solution must describe:

-- what configuration is required

-- how that configuration will take place

-- what happens if things are misconfigured

Is that too much to ask? I hope not. A little care in
the protocol design now will have big payoffs in usability
over the next few years.

-- Chip

---

From: Joel Halpern <[email-masked]>
Date: Mon, 9 Mar 1998 12:49:42 -0500 (EST)

This is just my personal take, but in the spectrum that Charlie suggested,
I think that this working group adds more value in the 50 nodes with no
configuration than it does in th 10,000 node case.
All solutions have scaling limits.  It is important to be aware of those
limits.  Trying to completely avoid them is a waste of time.

So, given the nature of manet, I would start by trying to figure out what
I need for assignment/management of addressing for completely dynamic
communication.  (Note that if there is a requestor/assignor, then one must
solve the problem of getting a multi-hop response back to someone who does
not yet have an address.)
Sepearately, we have already been discussing various techniques for
routing these addresses, assuming that they are assigned.

In each of these two areas, if there are ways to extend the scale without
losing the basic goals (autoconfig, dynamic routing, adaptability,
practicallity of gateway to the rest of the world) then it is worth
including such techniques.
It is not worth solving the problems of the entire internet.  And
somewhere between 100 and 100,000 nodes that is what you start trying to
do.

Yours,
Joel M. Halpern                         [email-masked]
Newbridge Networks Inc.

---

From: Joe Macker <[email-masked]>
Date: Mon, 09 Mar 1998 17:14:54 -0800

>limits.  Trying to completely avoid them is a waste of time.

I agree Joel.  Each solution will have scaling limits (not sure 50 is the
number, but it is definitely something way less than 10,000) and this is a
critical evaluation consideration.  We have "hundreds of routers" not
thousands in the charter and I think this seems reasonable as an upper
consideration limit for now.

>routing these addresses, assuming that they are assigned.

I would like to add that I feel that the manet initial goal and charter is
improvements to mobile routing approaches and interfaces within a mobile
routing area. The longer term dynamic address management appraoches are
highly debateable with some bordering on excellent thesis topics.  I
believe a manet "stub" network with a preassigned address domain and
improved operational mobile routing is something we can build and get
working with minimal infrastructure impact in the short term.  As Charlie
previous pointed out, people should be aware we are departing from the
localized subnet-based interface design paradigm for manet interfaces.
Does everyone understand this?  We should have the latitude and freedom to
apply dynamic address management protocols, where and how--as sensible--later.

Putting on my "research hat", robust distributed address assignment and
automagic configuration are important technical areas for mobile network
development.  But from the present manet perspective, these can be viewed
as separate and complementary problems to work over and above improved
routing technology.  I don't think it appropriate for the manet WG to
become the "solve it all" WG and keep expanding its charter.  Another
possibility is that as complementary problems are defined that the
formation of additional WGs that work closely with manet could be considered.

--In the near term, how deeply should the manet WG involve itself in the
dynamic address management issues and more importantly standardization?--