Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!decvax!decwrl!pyramid!hplabs!ucbvax!MIT-MULTICS.ARPA!JSLove From: JSLove@MIT-MULTICS.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Port Multiplexing Details Message-ID: <860521151644.774883@MIT-MULTICS.ARPA> Date: Wed, 21-May-86 11:16:00 EDT Article-I.D.: MIT-MULT.860521151644.774883 Posted: Wed May 21 11:16:00 1986 Date-Received: Thu, 22-May-86 06:19:48 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 122 Approved: tcp-ip@sri-nic.arpa 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.