Path: utzoo!utgpu!water!watmath!clyde!bellcore!faline!thumper!karn From: karn@thumper.bellcore.com (Phil R. Karn) Newsgroups: comp.protocols.tcp-ip Subject: Re: controlling IP "type of service" Summary: Packet radio interpretation of TOS Message-ID: <1076@thumper.bellcore.com> Date: 12 May 88 04:21:14 GMT References: <8805101659.AA16832@fiona50a.CCS.Northeastern.EDU> Organization: Bell Communications Research, Inc Lines: 27 > Do any of the popular implementations actually try to set this > field, [TOS] and does it affect the delivered performance of the network? Mine (the KA9Q package) does. My IP interprets the "delay" and "reliability" bits in the AX.25 (amateur packet radio) subnet driver as follows: 1. If the "low delay" bit is set, send the datagram in an unnumbered information (UI) frame. There is no link level flow control or acknowledgment on these frames. 2. Else if the reliability flag is set, send the datagram as one (or more) regular information (I) frames, opening a new link connection if necessary. I frames are acknowledged and flow controlled at the link layer according to LAPB (the protocol on which AX.25 is based). The "or more" part refers to the possible use of subnet fragmentation and reassembly to keep the physical frames small without imposing an unreasonably small MTU on the IP layer. 3. Else use the interface's default encapsulation mode. Although the driver does look at these bits, this is just a hook for future use. At present my applications do not give the user the ability to control these bits in generated datagrams. The default mode is presently used for all datagrams. Phil