Community Hub0 Subscribers
Community hub
Type of service
View on Wikipediafrom Wikipedia
The type of service (ToS) field is the second byte of the IPv4 header. It has had various purposes over the years, and has been defined in different ways by five RFCs.[1]
Prior to the redefinition, the ToS field could specify a datagram's priority and request a route for low-latency, high-throughput, or highly-reliable service. Based on these ToS values, a packet would be placed in a prioritized outgoing queue,[2] or take a route with appropriate latency, throughput, or reliability. In practice, the ToS field never saw widespread use outside of US Department of Defense networks. However, a great deal of experimental, research, and deployment work has focused on how to make use of these eight bits, resulting in the current DS field definition.
The modern redefinition of the ToS field (as well as the Traffic Class field in IPv6 packets) splits this byte into a 6-bit Differentiated Services (DS) field[3] and a 2-bit Explicit Congestion Notification (ECN) field.[4] While Differentiated Services is somewhat backwards compatible with ToS, ECN is not.
History
[edit]The Type of Service field in the IP header was originally defined in RFC 791, and has been interpreted for IP Precedence and ToS ever since. The definition was largely derived from a US DoD Specification JANAP-128, which defines message multilevel precedence and preemption. It defined a mechanism for assigning a precedence to each IP packet, as well as a mechanism to request specific treatment such as high throughput, high reliability or low latency, etc. In the RFC 1349 update, the Monetary Cost bit is introduced (this bit was previously marked "Reserved for Future Use"). Section 2.4 of RFC 1583 (OSPFv2) introduces a ToS-aware routing method.
In practice, only the IP Precedence part of the field was ever used outside US DoD networks: the higher the value of the IP Precedence field, the higher the priority of the IP packet. Some US DoD networks did use the delay bit for route selection between oceanic cable paths and Satellite Communication (SATCOM) paths when both paths existed. IPv6 has never had an IPv4-like "traditional" ToS field, partially because the authors were aware of DiffServ efforts at its drafting (RFC 2460 Section 7).
In RFC 2474 the definition of this entire field was changed. It is now called the "DS" (Differentiated Services, "DiffServ") field and the upper 6 bits contain a value called the "DSCP" (Differentiated Services Code Point). The upper 3 bits of DS maintains compatibility with IP Precedence. Since RFC 3168, the remaining two bits (the two least significant bits) are used for Explicit Congestion Notification.
RFC 8622 added lower-effort (LE) DS for traffic that may be pre-empted by other traffic (best-effort traffic). It is intended for background traffic of low precedence, such as bulk data transfers with low priority in time.
Allocation
[edit]Precedence and ToS
[edit]Prior to its deprecation, the Type of Service field was defined as follows from RFC 791:
| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
|---|---|---|---|---|---|---|---|
| Precedence | Type of Service | Unused (0) | |||||
Precedence was a 3 bit field which treats high priority packets as more important than other packets. If a router is congested and needs to discard some packets, it will discard packets having lowest priority first. Although precedence field was part of IP version 4, it was never used.
RFC 1349 introduced an additional "lowcost" field. The four available ToS bits now becomes:
| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
|---|---|---|---|---|---|---|---|
| (IP Precedence) | lowdelay | throughput | reliability | lowcost (RFC 1349) | (Must be zero) | ||
The naming here follows the convention of Unix operating systems.[5] RFC 1349 and RFC 1060 only show examples of one bit used at a time for application-default values, although RFC 791 mentions that at most two of the three indications it has should be set nominally. One such use is known from mod_iptos.[6]
Because the last three bits went through many definitions prior to RFC 2474 (see below), documentation and implementations may be confusing and contradictory.
DSCP and ECN
[edit]RFC 2474 (which was released in December 1998) reserved the first six bits of the DS (or IPv4 ToS) field for the Differentiated Services Code Point (DSCP), and RFC 3168 reserved the last two bits for Explicit Congestion Notification.
| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
|---|---|---|---|---|---|---|---|
| DSCP | ECN | ||||||
DSCP defines a Class Selector (CS) naming to each value it defines, mirroring what would have been interpreted as the IP Precedence if one follows the older specification:
| DSCP Name | DS Field Value (Dec) | IP Precedence (Description) |
|---|---|---|
| CS0 | 0 | 0: Best Effort |
| LE | 1 | n/a |
| CS1, AF11-13 | 8,10,12,14 | 1: Priority |
| CS2, AF21-23 | 16,18,20,22 | 2: Immediate |
| CS3, AF31-33 | 24,26,28,30 | 3: Flash - mainly used for voice signaling |
| CS4, AF41-43 | 32,34,36,38 | 4: Flash Override |
| CS5, EF | 40,46 | 5: Critical - mainly used for voice RTP |
| CS6 | 48 | 6: Internetwork Control |
| CS7 | 56 | 7: Network Control |
DSCP Nomenclature:
- CS
- Class Selector (RFC 2474)
- AFxy
- Assured Forwarding (x=class, y=drop precedence) (RFC 2597)
- EF
- Expedited Forwarding (RFC 3246)
- LE
- Lower-Effort (RFC 8622)
The above table, with individual values written out for values of the entire ToS field (not to be confused with the little-used 5-bit part):
| DSCP Dec | ToS value | IP Prec |
|---|---|---|
| 0 | 0 | 0 |
| 8 | 32 | 1 |
| 10 | 40 | 1 |
| 14 | 56 | 1 |
| 18 | 72 | 2 |
| 22 | 88 | 2 |
| 24 | 96 | 3 |
| 28 | 112 | 3 |
| 34 | 136 | 4 |
| 36 | 144 | 4 |
| 38 | 152 | 4 |
| 40 | 160 | 5 |
| 46 | 184 | 5 |
| 48 | 192 | 6 |
| 56 | 224 | 7 |
Note: In the above table, ToS is shown in decimal format. However, many routers express ToS in hex format.
Example: mixed interpretation
[edit]Let's start with an IP precedence of 1, or 001 in binary. The entire ToS field would then be 001 00000, assuming that the unused 5 bits are zero. The DSCP can be interpreted by resegmenting to 001000 00, where 001000 = 8 is the DSCP value, corresponding to CS1.
Software support
[edit]Although not frequently used, IP ToS definitions are widely found in netinet/ip.h of Unix-like or Unix operating systems as IPTOS_FIELDNAME macros.[5] The "lowcost" field is commented out in OpenBSD due to its newer use for indicating ECN support.[5] Remnants of the old RFC 1349 terminology can be found in Transmission 2.93[7] as well as other tools that support setting this field.
An old Apache module "mod_iptos", once packaged in Ubuntu, notes that a way to use multiple RFC 1349 option bits together emerged after some point.[6]
See also
[edit]References
[edit]- ^ RFC 791, RFC 1122, RFC 1349, RFC 2474, and RFC 3168. For a full history of the ToS field, see section 22 of RFC 3168.
- ^ http://www.tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.qdisc.classless.html Linux Advanced Routing & Traffic Control
- ^ RFC 3260 Section 4
- ^ RFC 3168 Section 5
- ^ a b c "openbsd/src:sys/netinet/ip.h". GitHub. Retrieved 10 October 2018.
- ^ a b Gaudet, Dean. "mod_iptos.c (mod_iptos 1.0)". Archived from the original on 10 October 2018. Retrieved 10 October 2018.
- ^ "transmission 2.93:libtransmission/session.c". GitHub. Retrieved 10 October 2018.
Further reading
[edit]- John Evans, Clarence Filsfils (2007). Deploying IP and MPLS QoS for Multiservice Networks: Theory and Practice. Morgan Kaufmann. ISBN 978-0123705495.
External links
[edit]Type of service
View on Grokipediafrom Grokipedia
Introduction
Definition and Purpose
The Type of Service (ToS) field is an 8-bit field within the IPv4 header that provides an indication of the abstract parameters for the quality of service (QoS) desired by a datagram, guiding the selection of transmission paths or services in the network based on tradeoffs among low delay, high throughput, high reliability, and potentially increased cost.[1] Introduced in the original Internet Protocol specification, this field allows packets to specify desired handling characteristics, such as normal or low delay, normal or high throughput, and normal or high reliability, with the overall use of these indications possibly raising the service cost in terms of network resources or monetary charges.[1] The primary purpose of the ToS field is to enable differentiated treatment of IP packets to support QoS requirements, allowing applications to request specific handling that influences routing and forwarding decisions at network nodes without needing complex negotiations.[1] For instance, it facilitates prioritizing time-sensitive traffic, such as voice over IP (VoIP) packets, over bulk data transfers by marking them for expedited forwarding behaviors that minimize delay and jitter.[4] This mechanism helps achieve service differentiation in shared networks, ensuring critical applications receive appropriate resources amid varying loads. Unlike reservation-based QoS systems that maintain per-flow state across network elements—such as those using the Resource Reservation Protocol (RSVP)—the ToS field supports stateless service classes by simply marking packets to trigger predefined per-hop behaviors at routers, promoting scalability for large-scale deployments.[5] In contemporary networking, the ToS field has been repurposed to carry Differentiated Services Code Point (DSCP) values, extending its role in modern QoS architectures while preserving backward compatibility.[3]IPv4 Header Context
In the IPv4 header, the Type of Service (ToS) field occupies the second byte, consisting of 8 bits immediately following the 4-bit Version field and the 4-bit Internet Header Length (IHL) field, within the standard 20-byte minimum header length.[1] This positioning ensures that the ToS field is always present and fixed in size, without any variable-length extensions or options that could alter its location or length, unlike the optional fields that follow the fixed header portion based on the IHL value.[1] The ToS field interacts with other IPv4 header fields to guide packet processing and routing decisions at network devices. Specifically, routers use the ToS value alongside the destination address to select paths that prioritize quality of service attributes, such as delay or throughput, while the Time to Live (TTL) field limits hop counts to prevent loops, the Protocol field identifies the upper-layer payload for demultiplexing, and the Header Checksum validates header integrity before forwarding. These interactions enable differentiated handling without altering core forwarding logic based solely on addressing.[1] IPv4's ToS field is a dedicated 8-bit construct unique to its header design, which includes provisions for optional extensions in other areas but maintains ToS as invariant. In contrast, IPv6 employs an equivalent 8-bit Traffic Class field in its streamlined 40-byte header, which omits variable options entirely and integrates similar QoS signaling directly into the fixed structure for improved processing efficiency.[6]Historical Evolution
Original ToS Specification
The Type of Service (ToS) field was introduced in the original Internet Protocol (IP) specification as an 8-bit field within the IPv4 header, designed to indicate the desired quality of service for packet transmission. Defined in RFC 791, published in September 1981 by the Defense Advanced Research Projects Agency (DARPA) Internet Program, the ToS field aimed to allow hosts to specify preferences for how their data should be handled by the network, enabling routers to differentiate treatment based on application needs. This feature was part of the broader effort to establish a connectionless, best-effort datagram service in IP, where the ToS provided a mechanism for rudimentary service differentiation without requiring complex reservations.[1] The original bit structure of the ToS field consisted of a 3-bit Precedence subfield followed by three individual Type of Service bits (D, T, R) and two reserved bits (both set to 0). The Precedence bits, ranging from 000 (routine) to 111 (network control), were intended to indicate the relative importance of the datagram, with higher values prioritizing critical traffic such as network control messages over routine user data. The subsequent bits were the Delay bit (D: 0 for normal delay, 1 for low delay), Throughput bit (T: 0 for normal throughput, 1 for high throughput), and Reliability bit (R: 0 for normal reliability, 1 for high reliability), with the two final bits reserved and set to 0. These bits were mutually exclusive in the sense that only one type of service indication (delay, throughput, or reliability) was expected to be set at a time, though the specification allowed for combinations in practice.[1] Routers were expected to interpret the ToS field to select appropriate paths or queue packets accordingly—for instance, routing low-delay packets over faster links or prioritizing high-throughput packets in congested networks to minimize delay, maximize throughput, or enhance reliability as indicated. However, the specification emphasized that support was not mandatory; routers were only required to transmit the ToS value unchanged and, if capable, attempt to approximate the requested service, leading to inconsistent implementations across early networks. This voluntary nature contributed to limited adoption, as many routers ignored the field, resulting in the ToS often being set to zero for default treatment.[1]Transition to Differentiated Services
The original Type of Service (ToS) field, as defined in RFC 791, encountered significant limitations due to its bit-based structure, which allowed combinations of delay, throughput, and reliability bits that were overly prescriptive and often ambiguous in practice, hindering effective implementation across diverse networks.[1] This approach lacked scalability for the evolving Internet, as the three-bit design restricted the provision of varied quality of service (QoS) levels without per-flow state management, prompting revisions in RFC 1349.[7] There, the ToS field was redefined as a four-bit enumerated value to eliminate multi-bit combinations, introducing a new value for cost minimization and reserving space for future extensions, though it still fell short of supporting aggregate-based QoS in large-scale deployments.[7] By the late 1990s, the Internet's growth demanded a more flexible QoS framework that could scale without the signaling overhead of Integrated Services (IntServ), which relied on resource reservation per flow and proved complex for core networks.[8] The Differentiated Services (DiffServ) architecture emerged to address this by enabling service differentiation through packet marking and simple per-hop behaviors, while maintaining backward compatibility with existing IP Precedence mechanisms to ease adoption.[8] This shift prioritized aggregate traffic handling over individual flows, reducing state requirements and supporting diverse services like premium bandwidth or assured delivery in commercial environments.[8] RFC 2474 formalized the transition by redefining the eight-bit ToS octet in IPv4 (and the equivalent in IPv6) as the Differentiated Services (DS) field, replacing the service-specific bits with a six-bit Differentiated Services Code Point (DSCP) to encode per-hop behaviors (PHBs) and a two-bit currently unused portion.[3] This structure allowed for 64 codepoints to specify forwarding treatments, with the lower three bits compatible with prior IP Precedence values (e.g., via class selector codepoints ending in '000') to ensure interoperability with legacy systems.[3] Complementing this, RFC 2475 outlined the DiffServ architecture, introducing PHBs as the core mechanism for defining observable forwarding actions at each hop, such as those later specified for Assured Forwarding (AF) to provide varying drop priorities and bandwidth assurances, and Expedited Forwarding (EF) for low-latency, low-loss transmission.[8] These PHBs enabled boundary nodes to classify and condition traffic aggregates, propagating simple behaviors through the network without end-to-end signaling, thus achieving scalable QoS tailored to the Internet's expansion.[8]Field Structure and Interpretation
The 8-Bit ToS Byte
The Type of Service (ToS) field occupies the second byte of the IPv4 header and consists of 8 bits, numbered from 0 (most significant bit, MSB) to 7 (least significant bit, LSB).[1] This binary structure enables the encoding of service parameters to influence packet handling during network traversal.[1] Over time, the interpretation of these bits has evolved to support advancing quality of service (QoS) requirements in IP networks.[3] In its original definition per RFC 791 (1981), the ToS byte allocated bits 0-2 to precedence, bit 3 to delay (D), bit 4 to throughput (T), bit 5 to reliability (R), and bits 6-7 as reserved (set to 0).[1] An interim revision in RFC 1349 (1992) redefined the structure by expanding the service bits to bits 3-6 for enumerated ToS values (minimizing delay, maximizing throughput, maximizing reliability, or minimizing cost), while retaining bits 0-2 for precedence and setting bit 7 to must-be-zero (MBZ).[7] The modern formulation, established by RFC 2474 (1998), repurposes the byte as the Differentiated Services (DS) field, with bits 0-5 dedicated to the 6-bit Differentiated Services Code Point (DSCP) and bits 6-7 as currently unused (CU).[3] Subsequently, RFC 3168 (2001) assigned bits 6-7 to Explicit Congestion Notification (ECN), completing the current 6-bit DSCP plus 2-bit ECN layout.[9] The following bit diagrams illustrate these allocations: Original (RFC 791):Bit: 0 1 2 3 4 5 6 7
+--+--+--+--+--+--+--+--+
|Pre|Pre|Pre| D | T | R | 0 | 0 |
+--+--+--+--+--+--+--+--+
Bit: 0 1 2 3 4 5 6 7
+--+--+--+--+--+--+--+--+
|Pre|Pre|Pre|TOS|TOS|TOS|TOS|MBZ|
+--+--+--+--+--+--+--+--+
Bit: 0 1 2 3 4 5 6 7
+--+--+--+--+--+--+--+--+
| DSCP | DSCP | DSCP | ECN| ECN|
+--+--+--+--+--+--+--+--+
Precedence, Delay, Throughput, Reliability Bits
The original Type of Service (ToS) field in the IPv4 header included three bits dedicated to precedence, occupying the most significant positions within the 8-bit field (bits 0-2).[1] These bits allowed for eight levels of priority, ranging from 0 (routine traffic) to 7 (network control, reserved for essential network management functions).[1] Lower values such as 2 (immediate, binary 010) were intended for urgent user traffic like voice or video, while 3 (flash, binary 011) supported applications requiring rapid handling, and 4 (flash override, binary 100) provided even higher urgency for critical overrides in military or emergency contexts.[1] Routers were required to process packets across all precedence levels, implementing queue service that prioritized higher values during congestion, though administrative filters could restrict lower precedences if configured.[10] The delay bit (bit 3) specified preferences for delivery speed, with a value of 0 indicating normal delay and 1 requesting low delay to minimize latency.[1] This bit was particularly suited for interactive applications, such as TELNET sessions or FTP control connections, where prompt response was essential over bulk data transfer.[7] Routers considering this bit in forwarding decisions would select paths or queue positions that favored quicker processing, though support was optional and often defaulted to normal handling if no low-delay routes existed.[10] The throughput bit (bit 4) addressed data rate needs, set to 0 for normal throughput and 1 for high throughput to prioritize bandwidth allocation.[1] Examples included bulk transfer protocols like FTP data phases or SMTP data transmission, which benefited from routes offering greater capacity to avoid bottlenecks.[7] In router implementations, this bit could influence path selection toward higher-capacity links, but during congestion, it might compete with other metrics, leading to fallback to standard routes.[10] The reliability bit (bit 5) focused on delivery assurance, with 0 denoting normal reliability and 1 requesting high reliability to emphasize error-free transmission and reduced packet loss.[1] It was recommended for protocols sensitive to datagram loss, such as SNMP management traffic or interior gateway protocols (IGPs), where additional router efforts like preferential queuing could protect against drops.[7] Routers might protect high-reliability packets in congested scenarios, provided this did not override precedence rules, though the bit's impact was advisory rather than mandatory.[10] These bits—delay, throughput, and reliability—were designed to guide routers in optimizing service quality, but their settings could conflict due to inherent trade-offs in network resources.[1] For instance, requesting low delay alongside high throughput might strain limited paths, as faster routes often had lower capacity; the specification advised setting at most two of these bits to avoid such issues, except in unusual cases.[1] Early routers handled conflicts by prioritizing exact matches in route tables and falling back to default (normal) service if no suitable path existed, rather than discarding packets, a approach termed "weak TOS" to ensure forward progress.[7] If no matching route was available at all, however, routers would generate an ICMP Destination Unreachable message with a TOS-specific code to indicate the failure.[10]| Precedence Value | Binary | Description | Example Usage |
|---|---|---|---|
| 0 | 000 | Routine | General user traffic[1] |
| 1 | 001 | Priority | Important business applications[1] |
| 2 | 010 | Immediate | Urgent user traffic, e.g., voice[1] |
| 3 | 011 | Flash | Rapid handling, e.g., video[1] |
| 4 | 100 | Flash Override | Critical overrides, e.g., emergency[1] |
| 5 | 101 | Critic/ECP | Critical for execution, e.g., DoD systems[1] |
| 6 | 110 | Internetwork Control | Network management[1] |
| 7 | 111 | Network Control | Essential infrastructure[1] |
DSCP and ECN Encoding
The Differentiated Services Code Point (DSCP) and Explicit Congestion Notification (ECN) together define the encoding within the 8-bit Differentiated Services (DS) field, which replaces the original Type of Service (ToS) octet in the IPv4 header and corresponds to the Traffic Class field in IPv6.[3] This field is structured such that bits 0-5 (MSB side) are allocated to the DSCP, while bits 6-7 (LSB side) are dedicated to the ECN field.[3][9] The DSCP value, represented as a 6-bit binary code (ranging from 000000 to 111111 in decimal 0 to 63), specifies the per-hop behavior (PHB) that a packet should receive at each network node, enabling differentiated treatment based on service classes such as expedited forwarding or assured forwarding.[3] The ECN encoding utilizes the 2-bit field to signal congestion without dropping packets, providing an alternative to traditional tail-drop mechanisms.[9] Defined in RFC 3168, the ECN bits support four codepoints, which indicate whether the transport is ECN-capable and the presence of congestion: Not-ECN-Capable Transport (Not-ECT, '00'), ECN-Capable Transport (ECT(0), '10'), ECN-Capable Transport (ECT(1), '01'), and Congestion Experienced (CE, '11').[9] These codepoints allow routers to mark packets with CE when congestion is detected, prompting ECN-capable endpoints (such as those using TCP) to reduce their sending rate, thereby mitigating queue buildup.[9] The ECT(0) and ECT(1) variants provide flexibility for future extensions, such as distinguishing between different marking behaviors, though ECT(0) is the standard for initial ECN deployment.[9] This combined encoding ensures compatibility with the Differentiated Services architecture while integrating congestion signaling.[3][9] In IPv4, the DS field directly overlays the legacy ToS octet, with DSCP subsuming the original IP Precedence bits (positions 0-2) through class selector codepoints ending in '000' to maintain backward compatibility with non-DS-aware devices.[3] ECN bits, previously designated as "Currently Unused" in RFC 2474, were explicitly allocated for this purpose in RFC 3168, ensuring that DS-compliant nodes process the full 8 bits without altering DSCP values during ECN marking.[3][9] The encoding is identical in IPv6, where the 8-bit Traffic Class field follows the same bit positioning.[9]| ECN Codepoint | Binary (Bits 6-7) | Meaning |
|---|---|---|
| Not-ECT | 00 | Non-ECN-capable transport; packets may be dropped on congestion. |
| ECT(0) | 10 | ECN-capable transport; mark with CE on congestion instead of drop. |
| ECT(1) | 01 | ECN-capable transport (alternative marking, for future use). |
| CE | 11 | Congestion experienced; endpoint should react as if packet was dropped. |
Allocation of Values
Standardized DSCP Values
The Differentiated Services Code Point (DSCP) values are allocated from a 6-bit field, providing 64 possible codepoints numbered 0 to 63 in decimal. According to IETF standards, these are divided into three pools to manage assignments: Pool 1 consists of 32 codepoints (binary format xxxxx0) reserved for standardized use via Standards Action; Pool 2 includes 16 codepoints (xxxx11) for experimental or local administrative use; and Pool 3 comprises 16 codepoints (xxxx01) for standardized use via Standards Action (updated from experimental/local use by RFC 8436).[11][12][13] This structure ensures that standardized codepoints in Pools 1 and 3 support interoperable per-hop behaviors (PHBs) across networks, while limiting experimental assignments to avoid conflicts.[11] Key standardized DSCP values from these pools define common PHBs for service differentiation. For instance, CS0 (decimal 0, binary 000000) is allocated for best-effort traffic, providing default forwarding without prioritization.[12] CS6 (decimal 48, binary 110000) is designated for network control traffic, such as routing protocols, to ensure high priority and low loss.[12] EF (decimal 46, binary 101110) supports expedited forwarding for low-latency applications, minimizing delay and jitter while bounding burstiness. Within the Assured Forwarding (AF) framework, AF11 (decimal 10, binary 001010) denotes class 1 with low drop probability, suitable for traffic tolerant of moderate delay but requiring protection from congestion.| DSCP Name | Decimal Value | Binary | PHB Purpose | Reference |
|---|---|---|---|---|
| CS0 | 0 | 000000 | Best effort (default) | RFC 2474 |
| CS6 | 48 | 110000 | Network control | RFC 2474 |
| EF | 46 | 101110 | Expedited forwarding (low latency) | RFC 3246 |
| AF11 | 10 | 001010 | Assured forwarding class 1, low drop | RFC 2597 |
ECN Codepoints
The Explicit Congestion Notification (ECN) mechanism utilizes the two least significant bits of the Differentiated Services Code Point (DSCP) field in the IP header, known as the ECN field, to convey four distinct codepoints that enable congestion signaling without packet drops. These codepoints are: 00, indicating Not ECN-Capable Transport (Not-ECT), where endpoints do not support ECN and routers may drop packets during congestion; 01, denoting ECN-Capable Transport variant ECT(1), which signals ECN support and includes a nonce for protection against misbehaving receivers; 10, representing ECN-Capable Transport variant ECT(0), similarly indicating ECN capability without the nonce; and 11, signifying Congestion Experienced (CE), which routers set to notify endpoints of impending congestion instead of discarding packets.[9] The ECT(0) and ECT(1) codepoints are treated equivalently by routers for marking purposes, allowing senders to choose based on whether nonce verification is desired to prevent receivers from falsely acknowledging congestion.[9] ECN negotiation occurs primarily during the TCP three-way handshake, where the initiator sets the ECN-Capable Transport (ECT) codepoint in the IP header of the SYN packet and includes the ECN-Echo (ECE) and Congestion Window Reduced (CWR) flags in the TCP header to propose ECN usage. The responder confirms support by echoing the ECE flag in the SYN-ACK and setting ECT in the IP header, after which subsequent packets use ECT until congestion is signaled via CE marking by a router, prompting the receiver to notify the sender via ECE for congestion window adjustment.[9] Routers configured for ECN, often in conjunction with active queue management like Random Early Detection (RED), monitor queue lengths and mark packets with the CE codepoint when thresholds are approached, rather than enqueuing or dropping them, thereby preserving packet delivery while signaling overload.[9] Defined in RFC 3168, ECN applies to the IP layer by repurposing bits in the IPv4 Type of Service (ToS) octet and the IPv6 Traffic Class field, with adaptations for TCP through header flags and provisions for other transports like RTP, though RTP-specific behaviors were left for future specification.[9] For IPv6, core header support exists directly in the Traffic Class, but extensions via IPv6 extension headers enable ECN propagation in tunneled or encapsulated scenarios.[9] The mechanism does not alter IPv6's lack of header checksums, avoiding the incremental update issues present in IPv4.[9] By marking rather than dropping packets, ECN reduces latency in TCP flows, particularly for short-lived or delay-sensitive connections, as it avoids retransmission timeouts and the resulting exponential backoff delays associated with lost packets.[9] Deployment studies indicate widespread support for ECN on web servers (over 90% for popular sites as of 2024), facilitating broader adoption for improved throughput and fairness in congested networks, though end-to-end negotiation rates remain lower at around 2-3% of clients as of mid-2025 due to uneven enablement across endpoints and potential middlebox interference.[15][16]Backward Compatibility Issues
One major challenge in transitioning from the original Type of Service (ToS) field to the Differentiated Services Code Point (DSCP) and Explicit Congestion Notification (ECN) encoding lies in ensuring precedence compatibility, where DSCP values are structured to align with the legacy IP Precedence bits from the IPv4 header. Specifically, for class selector codepoints defined in the Differentiated Services architecture, the DSCP is encoded such that its three most significant bits match the IP Precedence value, allowing legacy devices to extract the precedence as (DSCP >> 3) & 0x07 and apply corresponding treatment without modification.[3] This mapping, using codepoints of the form 'xxx000' in binary, ensures that higher precedence values receive preferential handling in mixed environments, as required by the class selector Per-Hop Behaviors (PHBs).[3] Tunneling protocols, such as those used in MPLS or VPNs, introduce additional compatibility issues by potentially rewriting the ToS byte during encapsulation and decapsulation, which can obscure or alter the intended DSCP markings across DiffServ domains. To mitigate this, RFC 2983 outlines models like the Pipe and Uniform approaches for handling Differentiated Services in tunnels: the Pipe model preserves the inner packet's DSCP at the tunnel egress for domain-specific treatment, while the Uniform model applies a single outer DSCP to simplify forwarding but risks losing granularity.[17] Guidelines emphasize performing traffic conditioning on the outer header before encapsulation or statically mapping DSCPs at egress to avoid unintended rewrites, particularly when tunnels span non-DiffServ-aware segments.[17] Legacy devices that do not support DiffServ often ignore the full DSCP and revert to interpreting the ToS byte using the original semantics, focusing solely on the IP Precedence bits while disregarding the expanded codepoint space. This behavior can lead to inconsistent QoS application, as non-DiffServ routers forward packets based on the upper three bits alone, potentially demoting finer-grained DSCP distinctions to routine service.[3] In environments with mixed hardware, such devices may drop or queue packets suboptimally if the lower DSCP bits signal priorities they cannot recognize.[3] A common pitfall arises from the misinterpretation of bits previously unused in the DSCP encoding but now allocated to ECN, where legacy ToS-aware devices may treat the ECN codepoints (bits 1 and 0 of the ToS octet) as the original delay, throughput, or reliability indicators from RFC 791. This can result in erroneous queuing decisions, such as prioritizing packets marked for congestion experienced (CE) as low-delay traffic, thereby exacerbating network congestion rather than alleviating it.[9] To address this, ECN compatibility requires non-ECN devices to either clear these bits or avoid modifying them, but persistent legacy support often leads to CE codepoints being erased, disabling effective congestion notification and yielding suboptimal end-to-end QoS.[9]Implementation and Support
Hardware and Router Support
Routers implement Type of Service (ToS) processing through classification, marking, and policing mechanisms to enforce Quality of Service (QoS) policies based on the Differentiated Services Code Point (DSCP) values derived from the ToS byte. At the ingress interface, packets are classified by examining the DSCP field to identify traffic types and map them to appropriate QoS treatments, such as assigning them to specific queues or applying rate limits.[18] Marking involves setting or modifying the DSCP value at either ingress or egress to ensure consistent end-to-end treatment across network domains, while preserving the original markings if trust boundaries are configured.[18] Policing, often applied at ingress, enforces bandwidth limits by dropping or remarking excess traffic exceeding committed rates defined per DSCP class, preventing congestion from lower-priority flows.[19] Queueing mechanisms in routers leverage DSCP values to schedule packet transmission during congestion, prioritizing higher-value traffic to meet service level agreements. Weighted Fair Queuing (WFQ) assigns weights to flows or classes based on DSCP, dynamically allocating bandwidth proportionally so that packets with higher DSCP (e.g., EF for expedited forwarding) receive greater shares without starving lower-priority traffic.[20] Priority Queuing (PQ), including variants like Low Latency Queuing (LLQ), establishes strict hierarchies where high-DSCP traffic (such as voice with DSCP 46) is dequeued before others, ensuring low delay for time-sensitive applications while WFQ handles the remaining queues.[18] These mechanisms integrate with class-based policies, where DSCP-based class maps direct packets to dedicated queues for fair or prioritized servicing.[21] Hardware support for ToS/DSCP processing relies on Application-Specific Integrated Circuits (ASICs) and Field-Programmable Gate Arrays (FPGAs) in modern routers and switches to handle classification and queueing at wire speed. For instance, Cisco ASR 9000 series routers, equipped with Ethernet line card ASICs, support up to 16 queues per Layer 3 class in 16Q mode, with DSCP values mapped to these queues (e.g., one priority queue for high DSCP like EF and multiple weighted queues for others), enabling scalable QoS across thousands of classes.[22] This ASIC-based architecture allows simultaneous support for up to 64 unique DSCP markings on IPv4/IPv6 traffic, with hardware-accelerated mapping that maintains full interface scale on high-density ports.[22] In high-speed environments, the performance impact of ToS/DSCP inspection remains minimal, as it is embedded in the hardware forwarding pipeline of 10 Gbps and faster Ethernet interfaces, achieving line-rate processing without introducing measurable latency or throughput degradation under normal loads.[23]Software and OS Configuration
In operating systems such as Linux and BSD variants, applications can set the Type of Service (ToS) field, now interpreted as the Differentiated Services Code Point (DSCP) and Explicit Congestion Notification (ECN) bits, using thesetsockopt() system call with the IP_TOS socket option from the IPPROTO_IP level.[24] This option allows specifying an 8-bit value that encodes the desired DSCP and ECN codepoints in outgoing IP packets.[25] For example, the constant IPTOS_LOWDELAY (0x10) sets the low delay bit in the legacy ToS interpretation (RFC 791), resulting in a TOS byte value that, under DiffServ, yields the non-standard DSCP 4, which may not receive prioritized treatment in modern networks.[24][1][3]
By default, most operating systems transmit packets with a DSCP value of 0, indicating best-effort service unless explicitly configured otherwise.[26] On Linux, system-wide marking of the DSCP field can be achieved using the iptables firewall in the mangle table, which alters packet headers before routing; for instance, the -j DSCP --set-dscp target sets the 6-bit DSCP value (e.g., to 46 for Expedited Forwarding).[27]
Applications, particularly those requiring low-latency handling, commonly set specific DSCP values via socket options; VoIP software such as SIP clients often marks voice packets with DSCP 46 (EF) to ensure priority treatment for real-time audio streams.[18] Linux's traffic control (tc) utility complements this by classifying and shaping outbound traffic based on the ToS/DSCP field, using filters to direct packets into priority queues without altering the field itself.[28]
For monitoring and verification, tools like Wireshark allow filtering captured packets by DSCP value using display filters such as ip.dsfield.dscp == 46 to isolate EF-marked traffic.[29] Additionally, the ip route show command displays policy-based routing tables that can select routes based on the ToS field, enabling inspection of how the kernel routes packets according to their DSCP markings.[30]