[e2e] Port numbers, SRV records or...?

[John Day]

At 12:12 -0400 2006/08/12, Keith Moore wrote:
>>>It is very hard to avoid passing IP addresses (or names of
>>>attachment points) in applications protocols.  Sure you can pass
>>>some other kind of identifier, but that requires a fast,
>>>up-to-date, accurate, robust, scalable indirection service.  It's
>>>really difficult to provide that service in such a way that's
>>>suitable for a wide range of
>>
>>Yes, but there seems to be a contradiction.  Are we saying we have to
>>  use IP addresses because it is impossible to build a system that
>>would provide the fast, up-to-date, accurate, robust, scalable
>>indirection service?
>
>perhaps not impossible, but we don't have a worked example.
>
>>Sort of begs the question as to why IP addresses work then.   If
>>anything, they should change more frequently than some form of 
>>"application-identiifer"
>
>not really, because the current internet doesn't support mobile 
>processes.  IP addresses work well enough for referrals in an 
>internet where hosts generally have fixed locations, processes 
>cannot be mobile, there is only a single global addressing realm, 
>and the network itself is small and/or relatively static (thus not 
>requiring renumbering).  if they didn't work "well enough" under 
>those conditions, we wouldn't still be able to get away with using 
>DNS.
>
>today an application identifier (not that I would call them that) 
>would be analogous to IP address + port (not necessarily well known 
>port). but in a network that supported mobile processes, you would 
>not want to tie such an identifier to an IP address, nor would you 
>want to force them to be as ephemeral as port assignments. 
>basically you end up with something like a UUID except that you need 
>some way to facilitate lookup at a trusted lookup server.  so maybe 
>a combination of a UUID and a DNS name.

Agreed.  Makes for an interesting problem doesn't it?  Thinking this 
one through taking into account the nature of its use will tell us 
much about networks that we had not previously understood.  One of 
the problems I see in all of this is that we concentrate too much on 
solving specific problems and not deepening our understanding of what 
we are doing.  Pursuing the latter might actually lead to much better 
solutions than the more immediate approach.  In other words, more 
science and less engineering.

>
>>Passing IP addresses in applications is like passing physical memory
>>  pointers in Java.
>
>it's like passing physical memory pointers in an environment where 
>all objects are heap allocated and the system garbage collector is 
>free to move objects at any time.  (which might or might not be the 
>case for a Java implementation)

Managing virtual memory has been understood for sometime.  I can't 
imagine that a Java implementation could not handle such a thing.

>>>Also, even if ordinary apps don't
>>>need to deal with names of attachment points, some apps (such as
>>>network management apps) do.  Insisting on rigid layer separation
>>>makes the system unnecessarily complex and less adaptable to
>>>unanticipated needs.
>>
>>I don't see a problem.  What network management works with are not 
>>addresses.  It may use addresses or names to establish 
>>communication,
>>  but what it uses to do management are completely different.  Don't 
>>confuse the two.  Contrary to what 802 does, addresses are not 
>>serial
>>  numbers.
>
>network management does work with addresses, because one of the 
>things network management cares about are _where_ things are 
>attached to the network.  it also cares about _what_ is attached to 
>the network, but the most reliable way of determining what is 
>attached at any point on the network is to talk to that attachment 
>point.

I think we are speaking of different things.  You seem to be looking 
at it from the pov of things today and I am looking at it from the 
pov of how it should be. (a hopeless idealistic streak I have ;-)) 
Management does care about how things are attached and should be 
assigning addresses accordingly. But I think you have the causality 
backwards.  Addresses are assigned based on where it attached, not 
the other way around.  The address does not determine where it is 
attached.  Management must know where it is attached before the 
address can be assigned.  It is quirk of history that we tended to do 
it the other way.

>>My point was that if Moore's Law hadn't been turning quite so fast we
>>  would have had to have solved some of the scaling and other problems
>>  long before now.
>
>yes, but we would have "solved" many of those problems by 
>introducing other constraints.  e.g. we might have insisted that IP 
>addresses be stable identifiers.  then we would have outlawed NATs 
>and forced static routing on the net but also said that we don't 
>need multihoming or mobility support at the internet level because 
>they're just too expensive.

Huh?  You mean like so-called MAC addresses?  which are really serial 
numbers and not addresses at all.

Actually, I would contend would contend that addresses from any 
*address space* are always static.  They always identify the *same* 
place in the *topology* of the network (not graph).  The only 
question is whether there is an entity at that "place" to be 
identified.  ;-)

More I was referring to various scaling problems in routing such as 
table size.  Moore's Law allowed IP addresses to remain a flat 
address space far longer than it was healthy.  We never had to come 
to grips with the scaling problems inherent in what we were creating. 
If we had had to solve some of these problems it would have cleared 
up others along the way.

Take care,
John