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

[John Day]

Running a bit behind.

Snip
>
>  > 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 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.
>
>They currently do both for the registered numbers, at least as a
>convention, although individual host-pairs override that protocol
>meaning by a-priori (usually out-of-band) agreement.

Yes, there are lots of ad-hoc a-priori things going on.  This is how 
demos work not production systems.  We are spending far too much 
effort on the networking and it raises the cost of doing real work. 
This is just like the argument a few years ago that I take a PC of 
the the box and 8 hours later I have it configured and can use, it 
sort of.  I take Mac out of the box and plug it in, it boots and I am 
ready to work.

>
>>  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.)
>
>It's possible for that instance to hand-off other instances, as is done
>with FTP.

Yes, this creates a bottleneck, a single point of failure and 
security problems.

>  >> 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.
>
>That value must be 'standard' between the two endpoints, but as others
>have noted, need not have meaning to anyone else along the path.

Not really.  No requirement that it is standard.  It might be nice, 
but there is no requirement.

>...
>>>  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.
>
>The key question is "what is late bound". IMO, we could really use
>something that decouples protocol identifier from instance (e.g.,
>process demultiplexing) identifier.
>
>>>  In discussing the differences between email and instant messaging, I
>>>  came to
>>>  believe that we need to make a distinction between "protocol" and
>>>  "service".
>>>  The same protocol can be used for very different services, according
>>>  to how it
>
>This argues for three fields: demux ID (still needed), protocol, and
>service name.

Well, that is part of it.

>At that point, we could allow people to use HTTP for DNS exchanges if
>they _really_ wanted, rather than the DNS protocol. I'm not sure that's
>the point of the exercise, but modularity is a good idea.

Band-aids on band-aids.

Take care,
John