Stevens@A.ISI.EDU (Jim Stevens) (01/06/88)
2 Questions about IP & TCP Precedence: (1) The IP Request For Comments (RFC-791) and IP Military Standard (MIL-STD-1777) specify that Type Of Service (TOS) including precedence is a parameter that can be passed from the upper layer protocols to IP during a SEND operation and can be passed from IP to the upper layer protocols during a RECEIVE operation. How many IP implementations support this? How many people actually use this? (2) The TCP Military Standard (MIL-STD-1778) specifies the actions that TCP is to perform based upon the precedence passed up from IP in the TOS. The TCP Request For Comments (RFC-793) allows implementations to optionally perform precedence based upon the TOS passed up from IP. How many TCP implementations support this? How many people actually use this? Jim -------
lekash@ORVILLE.NAS.NASA.GOV (John Lekashman) (01/06/88)
2 Questions about IP & TCP Precedence: (1) The IP Request For Comments (RFC-791) and IP Military Standard (MIL-STD-1777) specify that Type Of Service (TOS) including precedence is a parameter that can be passed from the upper layer protocols to IP during a SEND operation and can be passed from IP to the upper layer protocols during a RECEIVE operation. How many IP implementations support this? How many people actually use this? I did a socket option to the kernel to allow a user program to set different values for the type of service. Currently this only consists of allowing it to set the value of that byte in the header. My feeling is that this should have some sort of abstraction of what sort of service is desired, and the TCP will cause the IP layer to set this byte value appropriately. The exact details of what sorts of service one might ask for, and appropriate TOS byte settings for such are not worked out. One major reason is attempting to figure out authentication mechanisms in a connectionless environment, ie preventing every random who feels like it setting his own personal workstation to get high bandwidth, low delay, high reliability, which then results in lossages to those who do the 'right thing' whatever that happens to be. Still, the setting allows us to send ftp data traffic over satellite channels, and telnet, acks and such over terrestrial lines. (with appropriate software switches in gateways and bridges. Maybe we'll even use it beyond the lab one day, if we get smart enough TCP's everywhere, which deal with satellites well. john
Mills@UDEL.EDU (01/06/88)
Jim, The fuzzball implementation supports TOS in IP and transport-level clients. The mapping is controlled by arguments to the IP function calls. TOS is interpreted by the queueing discipline as a priority, so that all IP packets with a TOS octet value of x are serviced before any TOS with value x-1. There are additional features for fairness and even a lie or two. The scheme should not be considered as conforming to specification, but as an experiment in queueing disciplines driven by pragmatic considerations. The NSFNET Backbone presently supports this discipline, which is currently in evaluation. Dave
LYNCH@A.ISI.EDU (Dan Lynch) (01/07/88)
Jim, As you must have figured out by now, no one supports the precedence and TOS fileds in any meaningful way. Those fileds were defined 15 years ago because they knew they had to be reserved up front if anyone could ever figure out how to use the information they purport to convey. Now we finally see one soul (Dave Mills, the tireless experimenter) using those fields to see if he can make some improvements in gateway behaviour. The trouble is that everyone has to play the "game" if those parameters are ever to have any use. The ISO equivalent protocols have also defined those parameters and I see no use of them there, either. Dan -------
PADLIPSKY@A.ISI.EDU (Michael Padlipsky) (01/08/88)
Why do you ask? -------