Subject: RE: [Tsvwg] multiaddressing

From: "Fleischman, Eric" <[email-masked]>
Date: Tue, 30 Nov 2004 11:01:20 -0800

Ted Faber [mailto:[email-masked]] wrote:
>>Fleischman, Eric wrote:
>> From: Ted Faber [mailto:[email-masked]] wrote:
>> 
>>>Why *not* DNS?  It's a distributed replicated
>>>1-to-many database.  It already returns lists of 
>>>network addresses associated with a string, and 
>>>there's a well-known API to get at those.  I don't 
>>>understand the additional dependency created here 
>>>unless the endpoints were not exchanging DNS names 
>>>to begin with. 
> 
>>DNS is good for a great many things. However, it isn't particularly 
>>good for supporting transitory, real-time, and short-lived 
>>information.

>None of which was in the problem statement.  The objection to DNS 
>(and there was one) was that using it "created another dependency," 
>not that the data was so volitile that it violated the DNS's 
>famously loose consistency requirements.

>I certainly agree with your assessment of DNS's suitabiltly for 
>handling rapidly changing data.  It's not good for passing out 
>doughnuts, either.

Ted,

Ignoring the doughnut comment, the view from my knot-hole is that this
discussion is hampered by differing and not fully articulated concept of
operations. I come from the MANET world where I think in terms of
constantly changing network topologies. Mobile IP and NEMO people think
in terms of end system or network mobility in the context of a stable
network environment. Other people think in terms of stable wire-line
networks with limited or no mobility. 

Multiple addresses may result from many causes, including mobility,
private address spaces (e.g., NATs), multi-homing, multiple protocol
support (e.g., IPv4 and IPv6), and IPv6 address usages. 

I assume that a preferable solution for this issue would scratch the
itches of all three types of environments (stable, mobile, highly
mobile). From where I sit, DNS is appropriate for stable wire-line
networks. It may or may not be appropriate for mobile (MIB and NEMO)
environments, depending on certain (thus far unstated) concept of
operations assumptions. However, it probably isn't appropriate for
highly mobile (MANET) environments for this particular usage.

--Eric

_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: Ted Faber <[email-masked]>
Date: Tue, 30 Nov 2004 13:09:05 -0800

> highly mobile (MANET) environments for this particular usage.

Despite my testy reply, I think we agree a bunch more than we disagree.
I understand what you're saying and I apologize for snapping.

As I'm sure you know, there's quite a bit to worry about beyond naming
when you consider endpoints that move often and need to maintain
communications when they do so.  You can constrain yourself into an
unsolvable problem pretty quickly.  IMHO, one should grab at tradeoffs
when they appear.  For example, the scale of most of the proposed MANETs
I've seen (other than sensor networks) means you can trade scope for
consistency in the naming system.  A small (by Internet standards)
network of endpoints that change their name-to-address mappings
frequently is a lousy fit for DNS, and there's no good reason to use it
there.  (Though having a name system tuned for that environment repsond
to DNS queries might be of practical use.)

The more of these sorts of discussions I have, the less I think that the
various uses of multi-homing (e.g., mobility, availability, load balancing)
are all that closely related.  I'm less optimisitic that there is a
single "multi-homing" solution that will scratch all those itches.  In
any case I think that it's an area in which people should tread
carefully and precisely.

I'm also concerned about making transport level changes without a clear
need or at least a clear indication of the tradeoffs.  I've yet to see a
case where a system is impossible without moving multihoming into the
transport or where all the hard parts are solved and the extra
kernel/layer crossings are the only think keeping the system from being
efficient.  I'm not saying that they don't exist, just that I haven't
seen clear demonstrations.

Finally endpoint to endpoint transport where both endpoints have static
single identifiers is tricky.  Building on that rather than complicating
it seems like the way to go.  I recognize that's an opinion, but it's
one that I hold pretty strongly.

-- 
Ted Faber
http://www.isi.edu/~faber           PGP: http://www.isi.edu/~faber/pubkeys.asc
Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG 
_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg