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

[Dave Crocker]

John Day wrote:
>> At every layer of a protocol architecture, there is a means of 
>> distinguishing services at the next layer up.  Without having done an
>> exhaustive study, I will nonetheless assert that there is always a field at
>> the current layer, for identifying among the entities at the next layer up.
> 
> Be careful here.  This is not really true.  The protocol-id field in IP for
> example identifies the *syntax* of the protocol in the layer above. (It can't

It distinguishes rather more than differentiating among syntaxes. You can't
seriously mean that it does not distinguish different semantics at the next
layer up?


> be the protocol because there could be more than one instance of the same
> protocol in the same system.  Doesn't happen often but it can happen.)
> Port-ids or sockets identify an instance of communication, not a  particular
> service.  Again, the well-known socket approach only works as long as there
> is only one instance of the protocol in the layer above and certainly only
> one instance of a "service." (We were lucky in the early work that this was
> true.)

The fact that I used "service" in one sentence and "entity" in another provides
a strong hint that I was speaking in general terms about the regular use of a
multiplexing mechanism, without trying to be highly precise about what is being
multiplexed.  For one draft of my note I was, in fact, tempted to use the term
"clients", since each of these things treats the next layer down as a service...


>> That field always has at least one standard, fixed value.  Whether it has
>> more than one is the interesting question, and depends on how the standard 
>> value(s) get used.  (If there is only one, then it will be used as a
>> dynamic redirector.)
> 
> Actually, if you do it right, no one standard value is necessary at all.  You
> do have to know the name of the application you want to communicate with, but
> you needed to know that anyway.

Since I suspect that whatever you have in mind carries an implicit standard
value, I'll have to ask for a concrete and detailed example of needing none.


>> What *does* matter is how to know what values to use. This, in turn, 
>> creates a bootstrapping/startup task.  I believe the deciding factor in
>> solving that task is when the binding is done to particular values.  Later
>> binding gives more flexibility -- and possibly better scaling and easier
>> administration -- but at the cost of additional mechanism and -- probably
>> always -- complexity, extra round-trips and/or reliability.
> 
> Not really. But again, you have to do it the right way.  There are a lot of
> ways to do it that do require all sorts of extra stuff.

Example?


>>      Similarly, the choice 
>> between relatively static, pre-registration versus dynamic assignment
>> depends upon how many services are involved and how quickly things change.
>> (Hmmm. Dynamic assignment requires pre-registration too...)
> 
> Well, it depends on other things as well. 

Since the "depends" was meant to be the important point, I'm entirely happy to
have the list of dependencies be longer than I cited.


 For example, if the identifiers
> being assigned are suppose to be location-dependent, then the assigner has to
> be able to interpret the location of the entity having the identifier

Hmmm. I think you are confusing how a layer uses multiplexing values with my
point that there are such things, and that they involve some amount of
pre-registration.

In the case of locations, this very much holds true.  After all, the location
references do not mean much if they are not pre-registered.

(And then I suppose you'll invoke global coordinates system as an example of no
prior registration; and I'll respond that the algorithm for using that system is
nothing but a pre-registration of the entire set of values...)


>> is implemented at operated.  Some folks will remember that in the 70's,
>> email had an instant messaging function.  While it involved a different FTP
>>  command than what we call email, the protocol was otherwise identical.
>> Today, the
> 
> C'mon Dave, you know better.  MAIL and MLFL were there for the same purpose

Wrong commands.

I meant:

>          MAIL SEND TO TERMINAL (MSND)
> 
>             This command is like the MAIL command, except that the data
>             is displayed on the addressed user's terminal, if such
>             access is currently allowed, otherwise an error is returned.
> 
>          MAIL SEND TO TERMINAL OR MAILBOX (MSOM)
> 
>             This command is like the MAIL command, except that the data
>             is displayed on the addressed user's terminal, if such
>             access is currently allowed, otherwise the data is placed in
>             the user's mailbox.
> 
>          MAIL SEND TO TERMINAL AND MAILBOX (MSAM)
> 
>             This command is like the MAIL command, except that the data
>             is displayed on the addressed user's terminal, if such
>             access is currently allowed, and, in any case, the data is
>             placed in the user's mailbox.
> 

Very popular with MIT, as I recall.


>> service distinctions are immediacy and reliability.  That is, email is 
>> reliable push, except that delivery is into a mailbox rather than the
>> screen, thereby making the last hop be "pull". This creates the view that
>> email is not immediate. But it *is* reliable, in that a message survives
>> most crashes by the host holding the message.  IM is push all the way, but
>> a message does not survive a crash.  My point, here, is that these are
>> implementation and operation distinctions, rather than inherent differences
>> in the exchange protocols.
> 
> Dave, email is not reliable. Email is connectionless.

Well, yeah, reliability is relative.  TCP is a long way from perfectly reliable,
too.  (I class connection-vs-connectionless as irrelevant, though of course
there has to be some sort of state maintained.)

But I'm going to take umbrage with your taking umbrage, since I stated the
specific kind of reliability I meant, namely surviving a crash of the system
holding the message, and was using it to distinguish between email and IM
service models.

(I forgot to add reference to the fact that IM typically does not have a retry
-- although some now do -- whereas email has rather more of it than some would
like...)


> One should write the service definition before writing the protocol. This is
> something that OSI understood. 

Sort of.  They understood that something along these lines was needed, but what
got supplied was not all that helpful, since most of the services were too
complex, etc.

(But, then, I usually say that TCP and OSI are exactly the same, except for all
the details.)


> SRVs are just one more band-aid.  

It can be argued quite strongly that much of the Internet's success has been by
the careful application of first-aid techniques.  Since the resulting splints,
bandages, etc. seem to last some number of decades, and since other techniques
for developing services seem to fail in an open environment, I'm not overly
inclined to make derogatory comments about the particulars that have succeeded.

None of which precludes looking for alternatives, of course...


> It is time to stop with the band-aids and
> figure out what the "answer" is. We need to know the goal we should at least
> approximate. 

That sounds consonant with what I suggested.

d/


-- 

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net