Path: utzoo!utgpu!watserv1!watmath!att!linac!pacific.mps.ohio-state.edu!zaphod.mps.ohio-state.edu!samsung!uunet!olivea!apple!agate!garnet.berkeley.edu!cliff
From: cliff@garnet.berkeley.edu (Cliff Frost)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: When is a link saturated?
Message-ID: <1991Jan23.182343.8505@agate.berkeley.edu>
Date: 23 Jan 91 18:23:43 GMT
References: <9101150900.AA08526@jerry.inria.fr> <9101150724.AA12358@mcsun.EU.net> <1991Jan21.141530.7031@ccs.carleton.ca> <1991Jan22.191059.5523@quick.com>
Sender: usenet@agate.berkeley.edu (USENET Administrator)
Reply-To: cliff@garnet.berkeley.edu (Cliff Frost)
Organization: ucb
Lines: 43

In article <1991Jan22.191059.5523@quick.com>, srg@quick.com (Spencer Garrett) writes:
|> ...
|> 
|> Not so.  A "connection" is identified by both source and destination
|> addresses *and port numbers*, so as long as the originator of each
|> session grabs a unique port number all is well.  My own networking
|> code does not shift away from the original well-known-port, and
|> multiple sessions work just fine.  I think the reason BSD does shift
|> port numbers may have something to do with the notion of "priviledged
|> port numbers" being those less than some small fixed number (1024
|> as I recall).  They may have thought it would be easier to implement
|> some security features if neither end of a regular session used
|> a small port number.

I think some details are missing and people are talking past eachother.
Here is my stab at making sense of what various folks are saying (comments
welcome):

I think for telnet sessions, the telnet well-known port will apear in every
packet.  This should make it possible for a device (bridge/router) to give
priority to telnet packets without maintaining per-connection information.

(Obviously, someone can set up a telnet server that listens to a different
port, and telnets to that port will not get the priority unless the device
maintains state.  Maybe this possibility is why someone claimed that it is
impossible to identify telnet connections merely by looking at packets in
isolation?)

For FTP the control connection is similarly identifiable.

For FTP the data connection can be, (and often?) is, negotiated away from
the well-known port.  This will make it difficult to give priority to ftp
data in the general case.

(Again, someone with control at both ends can play games with port numbers
to get around the priority scheme, but that same person can do this
whether or not the box in the middle maintains state.)

I think most TCP protocols are more like the telnet case than the ftp data
case, and the cisco scheme makes a lot of sense to me.

	Cliff Frost
	UC Berkeley (Computer Center, not related to BSD development)