QoS must also sometimes be implemented in private networks that have a
wide geographic reach and have bandwidth-starved links to remote locations.
In “Requirements for SIP Telephony Devices” [16], the following is recom-
mended: SIP devices must support the IPv4 DSCP field for RTP streams per
RFC 2597. The DSCP setting must be configurable to conform to the local net-
work policy. SIP telephony devices should:
■■ Mark RTP packets with the recommended DSCP for expedited forward-
ing (code point 101110)
■■ Mark SIP packets with DSCP AF31 (code point 011010)
Similar requirements have been developed for IPv6.
Best Effort Is for the Best Reasons
Following are some fundamental reasons why interdomain QoS is very diffi-
cult to implement and explain, in part, why QoS has not been deployed on the
Internet [17]:
■■ There is no scalable way to transfer authority between Internet
domains.
■■ Each Internet domain is a zone of authority and has its own
management.
■■ Domain authorities are run most often by commercial competitors.
■■ Different domains use different policies.
■■ There are no technologies available to protect from misconfigured
domains.
■■ All current interdomain QoS mechanisms create vulnerabilities that can
be exploited for theft of service or for DOS attacks.
■■ Interdomain flows are aggregates, but offending users from other
domains must be individually traced.
These reasons explain why the common practice on the Internet is to provi-
sion adequate bandwidth between adjacent Layer 2 networks (such as Gigabit
Ethernet) of interconnected domains and to monitor the network to avoid con-
gestion. Network loads of 30 to 40 percent are considered adequate for QoS
and for congestion avoidance.
Quality of Service for Real-Time Internet Communications 313