mckee@fiona50a.ccs (george mckee) (05/10/88)
Thinking about network pricing policies and accepting for the moment that relays don't grow on trees, I see on p.12 of RFC791 a description of a "Type of Service" field in an IP packet header that requests different levels of delay, throughput, and reliability, as well as specifying priorities ranging from "routine" through "flash override" and beyond. Do any of the popular implementations actually try to set this field, and does it affect the delivered performance of the network? (My Unix man page for ip(4P) says "other options are ignored".) - George McKee NU Computer Science
karn@thumper.bellcore.com (Phil R. Karn) (05/12/88)
> 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
Mills@UDEL.EDU (05/12/88)
Yes, although some question may remain on your "popular" qualifier. The present NSFNET Backbone gateways (Fuzzballs) do interpret the TOS and Precedence fields and order the queues accordingly. So far as I know, no other implementation, including the new NSFNET Backbone gateways (IBM), interpret those fields, with the possible exception of the SATNET/WIDEBAND gateways (LSI-11/Butterfly), which at one time mapped the TOS field to specialized services available in these packet-satellite nets. Dave
stjohns@beast.DDN.MIL (Mike St. Johns) (05/13/88)
Dave, by TOS, do you also mean the precedence bits? Mike
Mills@UDEL.EDU (05/13/88)
Mike, You're gonna love this: The queues are ordered by precedence; however, in case of TCP and either the source or destination port fields are TELNET, then assume a precedence of one. E pluribum unicorn and pass the rsh sauce, please. Dave
Mills@UDEL.EDU (05/13/88)
Mike, I lied and even misrepresented my own code. The queues are ordered by the value of the entire 8-bit TOS octet, including both precedence and DTR bits. In case of TCP and either source or destination port fields are TELNET, behave as if the D (delay) bit is set. Note the precedence bits are at the high-order end, so my previous message is morally right but factually inaccurate. What the heck, close enough for academic work. Dave
mcc@ETN-WLV.EATON.COM (Merton Campbell Crockett) (05/14/88)
Mike, Its been a while since I've read the RFP. Is Dave trying to say that a CRITIC is less important than a Flash or Flash Override? Merton
CERF@A.ISI.EDU (05/14/88)
Dave, does the precedence queueing inyour Fuzzballs account for some of the very long-delayed packets showing up in the Internet from time to time? Under heavy load, unless you have a time-dependent priority system, some packets may stay in queue quite a while as higher precedence traffic goes by. Vint
Mills@UDEL.EDU (05/15/88)
Merton, I takes the bits as they come. All ones is the greatest and all zeros the least most mortals could aspire. I plead resistant to any semantic exercise that attempts to match Internet reality with Precedence mappings. Dave
Mills@UDEL.EDU (05/15/88)
Vint, Verily in an FB(n) system dudes at higher priority levels can freeze out dudes at lower priority levels if the volume of traffic at the higher levels is sufficiently intense. There is now doubt that this occasionally occurs when the NSFNET Backbone is sore abused by certain 4.2bsd systems that have not upgraded to 4.3bsd with the Jacobson/Karels pollution controls (point made - I have not yet found a way to reliably identify 4.2bsd abusers and stamp their passports with priority zilch). While the freezees can shiver in the queues as the hotrods whiz by, they can't freeze for longer than their TTL, for most systems not over thirty seconds and for no systems longer than about four minutes. What usually happens is that, a packet below the eutectic can't live more than a few seconds before being preempted anyway. Such is live in the present 56-kbps world. Fancier schemes can readily be proposed to improve fairness with FB(n) systems, many of which were first proposed in the CTSS days when timesharing was losing its hyphenation. In context of six weeks the existing 56-kbps backbone is to live before being retired hy the new 1.5-Mbps backbone, there is small chance that these schemes will be implemented. There may be at least a month before the new backbone will have to face the same problems. Dave
CERF@A.ISI.EDU (05/16/88)
Dave, I forgot about TTL - in that case, how do you explain such long-delayed packets that arrive well in excess of TTL? Did they take paths that didn't examine TTL (e.g. hosts offering unauthorized gateway services?). Vint
Mills@UDEL.EDU (05/16/88)
Vint, So far as I know, no gateways except fuzzballs take care to calculate the actual time in queue when decrementing TTL. I of course would invite corrections to that presumption. Dave