Re: Port Multiplexing Details


J. Spencer Love (JSLove@MIT-MULTICS.ARPA)
Wed, 21 May 86 11:16 EDT


Are the general readership really interested in seeing this design
discussion continue on the TCP-IP list? I haven't received any
complaints about my long messages, but perhaps the interested parties
have already identified themselves. If this goes on much longer, should
we create a new list or something?

Putting the contact name in a TCP option in the header of the SYN packet
is cute: it solves the problem of gateways finding out what service
owns the connection. It is ugly to have to use a reserved port number
as well, but it would clearly be necessary so that hosts which didn't
implement the protocol would properly reject such packets.

However, putting the contact name in the header imposes length
limitations much more stringent than placing it in the data stream. It
also requires significant changes to all TCPs that participate in this
game. Perhaps that seems desirable to others, but I view both as
disasterous.

A 32 character name length may seem adequate, but it really isn't.
First, the number czar may give out long suffixes, like SYMBOLICS-,
THINKING-MACHINES-, HONEYWELL-INFORMATION-SYSTEMS-, and so on. Within
an organization, there may be further delegation, like OFFICE-SYSTEMS-,
ULTRIX-, SCRC-, and so on. It would be better to spell out names like
MANDELBROT, rather than having them compressed into MNDLBRT or given
less clear names like DCP3.

In the connection model we are currently using, there is no use for
contact arguments. There is no pressing need to implement them, since
we are using a stream protocol. The contact arguments can effectively
just appear in the TCP data stream. I believe that FINGER is a good
example. For TCP, the FINGER server arguments appear at the beginning
of the data stream. In fact, they are the whole data stream in one
direction. In CHAOS, the first packet contains the FINGER contact name
and the arguments. The only other packets to go in that direction are
the acknowledgements of the reply. TCPs generally assume a zero window
until the connection is established, so TCP requires at least two
packets to do what CHAOS does in one.

However, contact arguments can server as protocol specific options, and
it is easy to envision services that might be offered for more than one
stream protocol. For example, a system might support TCP, DECNET
(whatever their stream protocol is), CHAOS, TP4, X.25, and so on.
Defining an out-of-band mechanism for later use preserves flexibility.

Even though it makes life harder for security-minded gateways, I think
that the advantages of putting the contact information at the front of
the stream outweigh it. Protocols which must cross the secure gateways
can be assigned numbers. The gateways can reject multiplexor port SYN
packets.

Sending the contact information urgently is less disruptive since many
TCPs wouldn't have to be modified to permit this. The advantage of a
protocol that sends the contact information in the stream is that no
underlying mechanisms need be modified on either side of the connection.
The user side just sends the contact information at the beginning of the
stream, suitably delimited, and the server side reads it and acts on it.
The server TCP doesn't need to be modified; the server could make a new
connection to a numbered port and transfer bytes between the two
connections transparently.

Still, there may be TCPs that don't handle urgent data well. The
rationale for using a network newline (CRLF) to delimit the connection
name is that this is a standard delimiter sequence which is widely
understood across the network. Any ASCII character may be sent without
triggering recognition of this delimiter since a CRLF can be quoted as
CR NUL LF. (That is asking for trouble since there are implementations
which are defective in this department.) Certainly any printing
character can be sent with any implementation. Sending the contact
name, an optional space followed by contact arguments, and ending the
whole thing with a newline makes it very easy for both user and server.
The server can read one line from the TCP, which is often available as a
primitive. (If it isn't, there are other ways of ensuring that too much
data is not read from the TCP, like reading one character at a time.)

On Multics, either urgent or newline-delimited contact names would be
easy to implement. Interoperability would be possible in a very short
time, although improvements could be made later. A new option would
require significant changes to the underlying TCP for every system that
used it, a much bigger job.

UDP is a connectionless protocol. It has no options, and no memory from
one packet to the next. Requests are sent out to a well known port from
a local port which is used to identify the reply, if any.

There are two common scenarios which UDP is used for: a simple
announcement or query where each participating host sends at most one
packet, and as an underlying base for implementing some complex
protocol. To ask the time, for example, one host sends a UDP packet to
the time port; there may be no data in the packet (except the port
number to return the time to, which is part of the UDP header). The
reply contains only the time, perhaps as a 32 bit number. When it
arrives, the transaction is finished. This might be a good candidate
for a UDP-2 protocol which carried the name
"TIME-IN-SECONDS-SINCE-1970/01/01-00:00:00-GMT" rather than a well known
port number. At least one such protocol would get the short name
"TIME", I suppose, since the desire for precise names doesn't seem to be
widespread.

Other examples include TFTP and the remote virtual disk protocol. Both
of these applications maintain considerable state information about a
session and exchange many packets during the session. Using UDP-2 would
increase the overhead of the protocols, and might decrease the amount of
useful data sent in a datagram. For these sorts of services, some other
service to translate service names into port numbers would be much more
efficient.

The UDP lookup server, like Benson's version of the multiplexor server,
is easy to implement. UDP-2 might be nice, but is an even bigger job
than adding a new TCP option, and I never expect to see it in general
use.

Concerning contact names: how about reserving some TCP options as
"higher-level protocol specific"? The options could vary in meaning and
even length depending on which protocol (well known port) was used.
They would be valid only for the SYN packet. TCPs which play this game
could indicate in the LISTEN or OPEN call that they would accept such
options, and define a way for the application server to read them when
the connection is established. TCPs which don't implement the options,
or TCBs which don't accept the options would cause the connection to be
aborted rather than established. This precursor would make it possible
to implement St. Johns' version of the Named-Service server, and would
provide a mechanism like contact arguments.



This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:36:33 GMT