Path: utzoo!utgpu!watserv1!watmath!att!linac!pacific.mps.ohio-state.edu!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!lll-winken!prang!ejmmips.NOC.Vitalink.COM!ejm
From: ejm@ejmmips.NOC.Vitalink.COM (Erik J. Murrey)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: When is a link saturated?
Message-ID: <40@prang.TEST.Vitalink.COM>
Date: 31 Jan 91 21:05:42 GMT
References: <9101301444.AA13881@ccci>
Sender: usenet@prang.TEST.Vitalink.COM
Reply-To: ejm@ejmmips.NOC.Vitalink.COM (Erik J. Murrey)
Organization: Vitalink Communications
Lines: 27
Nntp-Posting-Host: ejmmips.noc.vitalink.com

In article <9101301444.AA13881@ccci>, tcs@ccci.UUCP (Terry Slattery) writes:
> For example, stock market data being sent from a ticker-plant to trader
> workstations probably has higher priority than a background FTP of a
> database dump between two systems.  Without the priority selection (or
> type-of-service), the market data may be delayed enough to seriously affect
> its value to the trader.
> 

This is a valid point.  However, a lot of the newer applications are
forced to use not-so-well-known-ports via portmapper, etc.  There just
aren't that many ports to reserve them for speicalized use.  This
presents a big problem to routers since they shouldn't have to track
the portmap requests to see what service is registered to what port.

This makes TOS via port # an unrealistic choice.

The real solution to this problem is to make sure that specialized
services that use variable port numbers set the low-delay, etc., bits
in the IP header to tell the routers to prioritize these packets.

And, yes, the BSD stack is capable of setting these bits with some
mods to the code via socket options.

---
Erik J. Murrey
Vitalink Communications NOC
ejm@NOC.Vitalink.COM	...!uunet!NOC.Vitalink.COM!ejm