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

[John Day]

At 0:55 -0700 2006/08/07, Dave Crocker wrote:
>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?
>

Nope.  When looking at this one has to consider what is the minimal 
amount one needs to know. All you *have* to know is enough that the 
layer above can interpret the bits.  Any semantics are the layer 
above's business.  As I said, this goes with the fact that the field 
does not allow designating more than one instance of the same 
protocol.  If it did, then it would involve more.  But then it would 
be a different field.

>  > 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...
>

Yes, of course it does.  Gosh, "service" and "entity"  it is 
beginning to sound like the language in the old (and wrong) OSI 
Model. ;-) Well-known sockets are a convention we have imposed and 
not a necessary part of the structure.  It has specific limitations. 
We were lucky in our early choices of applications that did not 
reveal the limitations.  All of our early applications were one per 
host.  This is also part of what lead to our mistaken infatuation 
with naming hosts.


>  >> 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.

Long story.  Currently with the editors.  Catch me off line and I can 
walk you through it.  Basically it all comes down to trying to patch 
an unfinished demo.

It is funny, but I have been finding that we have been acting like 
freshman engineers: not reducing the algebra before doing the 
arithmetic; and skipping steps because we think we know what they are 
and we don't. (Speaking metaphorically of course.)

>
>>>  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?

See above.

>
>>>       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.

I think we have different ideas of pre-register.  For example, 
so-called MAC addresses are pre-registered, but they aren't 
addresses.  They are serial numbers.

>(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...)

Nope, nothing so arithmetic.  The assigner must have a topological 
space in mind from which it draws identifiers for assigning is 
necessary, whether you consider this pre-registration, I can't say.

>
>>>  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.
>  >

These were not in RFC 542, which was the original inclusion of mail 
in FTP. These came much later if they were ever in FTP.

>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.)

The more useful distinction is whether processing the current PDU is 
affected by processing previous PDUs.  Each mail message is 
independent of the others.

>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...)

The retries are not e2e.  They are hop-by-hop. Isn't the difference 
that IM is more like IP'; whereas mail is more like a message switch? 
In IP, if a router crashes, you don't assume that it will have the 
packets it was buffering when it crashed, whereas with a message 
switch you do.

>
>>  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.)

Well sort of.   There were some significant differences. Most of the 
complexity in OSI was because it was 2 architectures under one 
umbrella fighting each other tooth and nail:  the European dedication 
to a connection-oriented model and the US dedication to a 
connectionless model.  How the European's ever thought X.25 could 
support applications of the 90s, I never understood but they did 
every thing they could to put it in which is where the complexity 
comes from.

If you pull out the connectionless side, i.e. (CLNP, TP4, Fast-byte, 
ACSE, CMIP) it takes the old ARPANet/Internet model one step further. 
(It still wasn't right, but it was another step.)  In particular, 
network addresses did not name subnetwork points of attachments as 
they do in IP.  Realizing that applications and application protocols 
were distinct, etc. CMIP was more powerful and yielded smaller 
implementations than SNMP, (although HEMS would have been better than 
either one) etc.  But as I say, it still wasn't right.

>
>>  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...

One can also argue that much of the Internet's success has been the 
liberal application of Moore's Law. It is really Moore's Law that has 
allowed the band-aids to do the job.  But what I see that concerns me 
are band-aids that don't really go anywhere and we all know what 
happens to systems that are the sum of a large number of band-aids. 
This is what concerns me.

This approach of relying on splints and band-aids is fine for a 
research network, not for basing the world economy.  The thing that 
scares me is that the band-aids have made the Internet more like DOS, 
than Multics, where we would settle for Unix, but we don't have that 
either (and I don't see that anyone realizes that is the problem.)

>
>>  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.

I would hope so.  ;-)

Take care,
John