Queuing algorithm to provide type-of-service for IP links
RFC - Unknown
(February 1988; No errata)
||RFC Editor Note
RFC 1046 (Unknown)
||Send notices to
Network Working Group W. Prue
Request for Comments: 1046 J. Postel
A Queuing Algorithm to Provide Type-of-Service for IP Links
Status of this Memo
This memo is intended to explore how Type-of-Service might be
implemented in the Internet. The proposal describes a method of
queuing which can provide the different classes of service. The
technique also prohibits one class of service from consuming
excessive resources or excluding other classes of service. This is
an "idea paper" and discussion is strongly encouraged. Distribution
of this memo is unlimited.
The Type-of-Service (TOS) field in IP headers allows one to chose
from none to all the following service types; low delay, high
throughput, and high reliability. It also has a portion allowing a
priority selection from 0-7. To date, there is nothing describing
what should be done with these parameters. This discussion proposes
an approach to providing the different classes of service and
priorities requestable in the TOS field.
We should first consider how we want these services to perform. We
must first assume that there is a demand for service that exceeds
current capabilities. If not, significant queues do not form and
queuing algorithms become superfluous.
The low delay class of service should have the ability to pass data
through the net faster than regular data. If a request is for low
delay class of service only, not high throughput or high reliability,
the Internet should provide low delay for relatively less throughput,
with less than high reliability. The requester is more concerned
with promptness of delivery than guaranteed delivery. The Internet
should provide a Maximum Guaranteed Delay (MGD) per node, or better,
if the datagram successfully traverses the Internet. In the worst
case, a datagram's arrival will be MGD times the number of nodes
traversed. A node is any packet switching element, including IP
gateways and ARPANET IMP's. The MGD bound will not be affected by
the amount of traffic in the net. During non-busy hours, the delay
provided should be better than the guarantee. If the delay a
Prue & Postel [Page 1]
RFC 1046 Type-of-Service Queuing February 1988
satellite link introduces is less than the MGD, that link should be
considered in the route. If however, the MGD is less than the
satellite link can provide, it should not be used. For this
discussion it is assumed that delay for individual links are low
enough that a sending node can provide the MGD service.
Low delay class of service is not the same as low Round Trip Time
(RTT). Class of service is unidirectional. The datagrams responding
to low delay traffic (i.e., Acking the data) might be sent with a
high reliability class of service, but not low delay.
The performance of TCP might be significantly improved with an
accurate estimate of the round trip time and the retransmission
timeout. The TCP retransmission timeout could be set to the maximum
delay for the current route (if the current route could be
determined). The timeout value would have to be redetermined when
the number of hops in the route changes.
High throughput class of service should get a large volume of data
through the Internet. Requesters of this class are less concerned
with the delay the datagrams have crossing the Internet and the
reliability of their delivery. This type of traffic might be served
well by a satellite link, especially if the bandwidth is high.
Another attribute this class might have is consistent one way
traversal time for a given burst of datagrams. This class of service
will have its traversal times affected by the amount of Internet
load. As the Internet load goes up, the throughput for each source
will go down.
High reliability class of service should see most of its datagrams
delivered if the Internet is not too heavily loaded. Source Quenches
(SQ) should not be sent only when datagrams are discarded. SQs
should be sent well before the queues become full, to advise the
sender of the rate that can be currently supported.
Priority service should allow data that has a higher priority to be
queued ahead of other lower priority data. It is important to limit
the amount of priority data. The amount of preemption a lower
priority datagram suffers must also be limited.
It is assumed that a queuing algorithm provides these classes of
service. For one facility to be used over another, that is, making
different routing decisions based upon the TOS, requires a more
Show full document text