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

Joe Touch touch at ISI.EDU
Tue Aug 8 06:34:33 PDT 2006

John Day wrote:
>> The thread seems to have veered off, into an interesting discussion of
>> history.
>>  There were a few responses to the main line of your query, and I am
>> hoping we
>> can consider it more extensively.
>> In what follows, I decided to make straight assertions, mostly to try to
>> engender focused responses.  I also decided to wander around the
>> topic, a bit,
>> to see what might resonate...
>> 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 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.

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

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

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

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.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 259 bytes
Desc: not available
Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20060808/afa769c2/signature.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 250 bytes
Desc: OpenPGP digital signature
Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20060808/afa769c2/signature-0001.bin

More information about the end2end-interest mailing list