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

[John Day]

At 15:20 -0400 2006/08/11, Keith Moore wrote:
>  > >sometimes the fixes are more complex and/or less reliable than the
>>  >kludges, and sometimes they don't provide much more in the way of
>>  >practical functionality.  or maybe they do provide a benefit in the
>>  >long-term, but little benefit in the near-term so the incentives aren't
>>  >in the right places to get them implemented.
>>
>>  Well, what I meant by that is there something fundamentally wrong. If
>>  you have kludges it is either because you are doing something you
>>  shouldn't (like passing IP addresses in application protocols) or
>>  there is something about how the architecture should be structured
>>  that you don't understand yet.
>
>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?  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"

Passing IP addresses in applications is like passing physical memory 
pointers in Java.


>applications.  (DNS, for example, falls way short of being able to do
>this).  If you can't provide such a service then you need to let
>applications build their own ways of finding the locations of their
>intended peers, and that requires exposing attachment points to
>applications.  From this point of view DNS is just another application,
>and just one of many ways for an application to learn IP addresses of
>intended peers.  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.

>
>>  (Sorry I am an optimist.  I don't believe that the right answer has
>>  to be kludgey.)
>
>Whether something is a kludge is a matter of judgement.  Notions of
>purity do not always agree with cost-vs-benefit evaluation.

Yea, I know.  Sometimes seems that way, but in my experience it 
usually turns out that it was a case of, shall we say, misplaced 
purity.

>  > Suppose that instead of turning the Moore's Law crank 15 times in the
>>  last 35 years, we had only turned it 3, but were still trying to do
>>  as much with the 'Net.
>
>Sort of an meaningless question, since without the low cost in cpu
>cycles there's no way we'd be sending live video over the net, probably
>not much high quality audio either because effective compression would
>still be fairly expensive.  and bit rates would be lower.  we might
>still have the web (with mostly text content) but we wouldn't have
>really effective large-scale search engines.    it would be really
>difficult to make web sites scalable for large populations. we'd see
>less dynamic content, more replication of resources to geographically
>diverse sites.  if we somehow managed to have as many hosts as we have
>in our current network, we would be doing routing very differently -
>relying much more on hierarchy because that's the only way we could
>compute forwarding tables.

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.  Moore's Law has allowed some to make the argument 
that we don't have to solve these hard problems just throw hardware 
at it.  Or perhaps more correctly, the research guys aren't solving 
the problem, so the guys building product have to do something so 
they throw hardware at it and for the time being the problem is 
"solved."

>  > >  > >It's interesting to reflect on how a new port extension mechanism,
>>  >>  >or replacement for ports as a demux token, would work if it took RFC
>>  >>  >1498 in mind.  I think it would be a service (instance) selector
>>  >>  >(not the same thing as a protocol selector) rather than a port
>>  >>  >number relative to some IP address.  The service selectors would
>>  >>  >need to be globally unique so that a service could migrate
>>  >>
>>  >>  You still need ports.  But you need to not conflate ports and
>>  >>  application naming.
>>  >>
>>  >>  >from one node or attachment point to another.  There would need to
>>  >>  >be some way of doing distributed assignment of service selectors
>>  >>  >with a reasonable expectation of global uniqueness,
>>  >>
>>  >>  service selectors?  No.  Application-names, yes.
>>  >
>>  >I think we're just arguing about what to call them.  I don't want to
>>  >call them application names partially because it's too easy to think of
>>  >an application name as something like "ftp" when that's the wrong level
>>  >of precision, and partially because to me an application is larger than
>>  >any single process that implements it.
>>
>>  Well, I don't like selectors because it too strongly implies some
>>  kind of central authority.  I don't want some one who wants to put a
>>  distributed application with his own protocol to have to see anyone
>>  to do it.
>
>ah, not my intent at all.  by selector I really meant just another kind
>of demux token, but one that is globally unique rather than relative to
>the concept of 'host'.  (though it occurs to me that it's difficult to
>assure global uniqueness of name-to-process bindings for processes
>that can migrate from one host to another without causing some fairly
>serious problems)

It is an interesting problem.

Take care,
John