One document matched: draft-ietf-aqm-fq-implementation-01.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- Some of the more generally applicable PIs that most I-Ds might want to use -->
<!-- Try to enforce the ID-nits conventions and DTD validity -->
<?rfc strict="yes" ?>
<!-- Items used when reviewing the document -->
<?rfc comments="no" ?>
<!-- Controls display of <cref> elements -->
<?rfc inline="no" ?>
<!-- When no, put comments at end in comments section,
otherwise, put inline -->
<?rfc editing="no" ?>
<!-- When yes, insert editing marks: editing marks consist of a
string such as <29> printed in the blank line at the
beginning of each paragraph of text. -->
<!-- Create Table of Contents (ToC) and set some options for it.
Note the ToC may be omitted for very short documents,but idnits insists on a ToC
if the document has more than 15 pages. -->
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<!-- If "yes" eliminates blank lines before main section entries. -->
<?rfc tocdepth="3"?>
<!-- Sets the number of levels of sections/subsections... in ToC -->
<!-- Choose the options for the references.
Some like symbolic tags in the references (and citations) and others prefer
numbers. The RFC Editor always uses symbolic tags.
The tags used are the anchor attributes of the references. -->
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<!-- If "yes", causes the references to be sorted in order of tags.
This doesn't have any effect unless symrefs is "yes" also. -->
<!-- These two save paper: Just setting compact to "yes" makes savings by not starting each
main section on a new page but does not omit the blank lines between list items.
If subcompact is also "yes" the blank lines between list items are also omitted. -->
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<!-- end of list of popular I-D processing instructions -->
<!-- end of list of processing instructions -->
<rfc category="info" docName="draft-ietf-aqm-fq-implementation-01"
ipr="trust200902">
<front>
<title abbrev="">On Queuing, Marking, and Dropping</title>
<author fullname="Fred Baker" initials="F.J." surname="Baker">
<organization>Cisco Systems</organization>
<address>
<postal>
<street/>
<city>Santa Barbara</city>
<code>93117</code>
<region>California</region>
<country>USA</country>
</postal>
<email>fred@cisco.com</email>
</address>
</author>
<author fullname="Rong Pan" initials="R." surname="Pan">
<organization>Cisco Systems</organization>
<address>
<postal>
<street/>
<city>Milpitas</city>
<code>95035</code>
<region>California</region>
<country>USA</country>
</postal>
<email>ropan@cisco.com</email>
</address>
</author>
<date/>
<area>Transport</area>
<workgroup>Active Queue Management</workgroup>
<abstract>
<t>This note discusses implementation strategies for coupled queuing and
mark/drop algorithms.</t>
</abstract>
<!--
<note title="Foreword">
</note>
-->
<!--
<texttable anchor="table_example" title="A Very Simple Table">
<preamble>Tables use ttcol to define column headers and widths.
Every cell then has a "c" element for its content.</preamble>
<ttcol align="center">ttcol #1</ttcol>
<ttcol align="center">ttcol #2</ttcol>
<c>c #1</c> <c>c #2</c>
<c>c #3</c> <c>c #4</c>
<c>c #5</c> <c>c #6</c>
<postamble>which is a very simple example.</postamble>
</texttable>
-->
</front>
<middle>
<!--
<t>There are multiple list styles: "symbols", "letters", "numbers",
"hanging", "format", etc.</t>
<t>
<list style="symbols">
<t>First bullet</t>
<t>Second bullet</t>
</list>
</t>
-->
<!--
<figure anchor="reference" title="Figure">
<artwork align="center">
<![CDATA[
ASCII artwork goes here...
]]>
</artwork>
</figure>
-->
<section title="Introduction">
<t>In the discussion of Active Queue Management, there has been
discussion of the coupling of queue management algorithms such as <xref
target="SFQ">Stochastic Fairness Queuing</xref>, <xref
target="VirtualClock">Virtual Clock</xref>, or <xref
target="DRR">Deficit Round Robin</xref> with mark/drop algorithms such
as <xref target="I-D.ietf-aqm-codel">CoDel</xref> or <xref
target="I-D.ietf-aqm-pie">PIE</xref>. In the interest of clarifying the
discussion, we document possible implementation approaches to that, and
analyze the possible effects and side-effects. The language and model
derive from the <xref target="RFC2475">Architecture for Differentiated
Services</xref>.</t>
<t>This note is informational, intended to describe reasonable
possibilities without constraining outc omes. This is not so much about
"right" or "wrong" as it is "what might be reasonable", and discusses
several possible implementation strategies. Also, while queuing might be
implemented in almost any layer, specifically the note addresses queues
that might be used in the Differentiated Services Architecture, and are
therefore at or below the IP layer.</t>
<!--
<section title="Requirements Language">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119"></xref>.</t>
</section>
-->
</section>
<section anchor="fq" title="Fair Queuing: Algorithms and History">
<t>There is extensive history in the set of algorithms collectively
referred to as "Fair Queuing". The model was initially discussed in
<xref target="RFC0970"/>, which proposed it hypothetically as a solution
to the TCP Silly Window Syndrome issue in BSD 4.1. The problem was that,
due to a TCP implementation bug, some senders would settle into sending
a long stream of very short segments, which unnecessarily consumed
bandwidth on TCP and IP headers and occupied short packet buffers,
thereby disrupting competing sessions. Nagle suggested that if packet
streams were sorted by their source address and the sources treated in a
round robin fashion, a sender's effect on end-to-end latency and
increased loss rate would primarily affect only itself. This touched off
perhaps a decade of work by various researchers on what was and is
termed "Fair Queuing," philosophical discussions of the meaning of the
word "fair," operational reasons that one might want a "weighted" or
"predictably unfair" queuing algorithm, and so on.</t>
<section anchor="gps" title="Generalized Processor Sharing">
<t>Conceptually, any Fair Queuing algorithm attempts to implement some
approximation to the <xref target="GPS">Generalized Processor
Sharing</xref> model.</t>
<t>The GPS model, in its essence, presumes that a set of identified
data streams, called "flows", pass through an interface. Each flow has
a rate when measured over a period of time; A voice session might, for
example, require 64 kbps plus whatever overhead is necessary to
deliver it, and a TCP session might have variable throughput depending
on where it is in its evolution. The premise of Generalized Processor
Sharing is that on all time scales, the flow occupies a predictable
bit rate, so that if there is enough bandwidth for the flow in the
long term, it also lacks nothing in the short term. "All time scales"
is obviously untenable in a packet network - and even in a traditional
TDM circuit switch network - because a timescale shorter than the
duration of a packet will only see one packet at a time. But it
provides an ideal for other models to be compared against.</t>
<t>There are a number of attributes of approximations to the GPS model
that bear operational consideration, including at least the
transmission quanta, the definition of a "flow", the unit of
measurement. Implementation algorithms have different practical
impacts as well.</t>
<section anchor="gps-quanta"
title="GPS Comparisons: transmission quanta">
<t>The most obvious comparison between the GPS model and common
approximations to it is that real world data is not delivered
uniformly, but in some quantum. The smallest quantum, in a packet
network, is a packet. But quanta can be larger; for example, in
video applications it is common to describe data flow in frames per
second, where a frame describes a picture on a screen or the changes
made from a previous one. A single video frame is commonly on the
order of tens of packets. If a codec is delivering thirty frames per
second, it is conceivable that the packets comprising a frame might
be sent as thirty bursts per second, with each burst sent at the
interface rate of the camera or other sender. Similarly, TCP
exchanges have an initial window, common values of which include 1,
2, 3, 4 <xref target="RFC3390"/>, and 10 <xref target="RFC6928"/>,
and there are also reports of bursts of 65K bytes at the relevant
MSS, which is to say about 45 packets in one burst, presumably
coming from TCP Segment Offload (TSO, also called TOE) engines.
After that initial burst, TCP senders commonly send pairs of
packets, but may send either smaller or larger bursts <xref
target="RFC5690"/>.</t>
</section>
<section anchor="gps-flow" title="GPS Comparisons: flow definition">
<t>An important engineering trade-off relevant to GPS is the
definition of a "flow". A flow is, by definition, a defined data
stream. Common definitions include: <list style="symbols">
<t>Packets in a single transport layer session ("microflow"),
identified by a five-tuple <xref target="RFC2990"/>,</t>
<t>Packets between a single pair of addresses, identified by a
source and destination address or prefix,</t>
<t>Packets from a single source address or prefix <xref
target="RFC0970"/>,</t>
<t>Packets to a single destination address or prefix,</t>
<t>Packets to or from a single subscriber, customer, or peer
<xref target="RFC6057"/>. In Service Provider operations, this
might be a neighboring Autonomous System; in broadband, a
residential customer.</t>
</list></t>
<t>The difference should be apparent. Consider a comparison between
sorting by source address or destination address, to pick two
examples, in the case that a given router interface has N
application sessions going through it between N/2 local destinations
and N remote sources. Sorting by source, or in this case by
source/destination pair, would give each remote peer an upper bound
guarantee of 1/N of the available capacity, which might be
distributed very unevenly among the local destinations. Sorting by
destination would give each local destination an upper bound
guarantee of 2/N of the available capacity, which might be
distributed very unevenly among the remote systems and correlated
sessions. Who is one fair to? In both cases, they deliver equal
service by their definition, but that might not be someone else's
definition.</t>
<t>Flow fairness, and the implications of TCP's congestion avoidance
algorithms, is discussed extensively in <xref target="NoFair"/>.</t>
</section>
<section anchor="gps-unit"
title="GPS Comparisons: unit of measurement">
<t>And finally, there is the question of what is measured for rate.
If the sole objective is to force packet streams to not dominate
each other, it is sufficient to count packets. However, if the issue
is the bit rate of an SLA, one must consider the sizes of the
packets (the aggregate throughput of a flow, measured in bits or
bytes). And if predictable unfairness is a consideration, the value
must be weighted accordingly.</t>
<t>Briscoe discusses measurement in his paper on <xref
target="RFC7141">Byte and Packet Congestion Notification</xref>.</t>
</section>
</section>
<section anchor="approx" title="GPS Approximations">
<t>Carrying the matter further, a queuing algorithm may also be termed
"Work Conserving" or "Non Work Conserving". A "work conserving"
algorithm, by definition, is either empty, in which case no attempt is
being made to dequeue data from it, or contains something, in which
case it continuously tries to empty the queue. A work conserving queue
that contains queued data, at an interface with a given rate, will
deliver data at that rate until it empties. A non-work-conserving
queue might stop delivering even through it still contains data. A
common reason for doing this is to impose an artificial upper bound on
a class of traffic that is lower than the rate of the underlying
physical interface.</t>
<section anchor="queue-algorithm"
title="Definition of a queuing algorithm">
<t>In the discussion following, we assume a basic definition of a
queuing algorithm. A queuing algorithm has, at minimum: <list
style="symbols">
<t>Some form of internal storage for the elements kept in the
queue,</t>
<t>If it has multiple internal classifications, <list
style="symbols">
<t>a method for classifying elements,</t>
<t>additional storage for the classifier and implied
classes,</t>
</list></t>
<t>potentially, a method for creating the queue,</t>
<t>potentially, a method for destroying the queue,</t>
<t>a method, called "enqueue", for placing packets into the
queue or queuing system</t>
<t>a method, called "dequeue", for removing packets from the
queue or queuing system</t>
</list></t>
<t>There may also be other information or methods, such as the
ability to inspect the queue. It also often has inspectable external
attributes, such as the total volume of packets or bytes in queue,
and may have limit thresholds, such as a maximum number of packets
or bytes the queue might hold.</t>
<t>For example, a simple FIFO queue has a linear data structure,
enqueues packets at the tail, and dequeues packets from the head. It
might have a maximum queue depth and a current queue depth,
maintained in packets or bytes.</t>
</section>
<section anchor="WRR" title="Round Robin Models">
<t>One class of implementation approaches, generically referred to
as "Weighted Round Robin", implements the structure of the queue as
an array or ring of sub-queues associated with flows, for whatever
definition of a flow is important.</t>
<t>On enqueue, the enqueue function classifies a packet and places
it into a simple FIFO sub-queue.</t>
<t>On dequeue, the sub-queues are searched in round-robin order, and
when a sub-queue is identified that contains data, removes a
specified quantum of data from it. That quantum is at minimum a
packet, but it may be more. If the system is intended to maintain a
byte rate, there will be memory between searches of the excess
previously dequeued.</t>
<?rfc needLines="20"?>
<figure anchor="roundrobin" title="Round Robin Queues">
<artwork align="center"><![CDATA[
+-+
+>|1|
| +-+
| |
| +-+ +-+
| |1| +>|3|
| +-+ | +-+
| | | |
| +-+ +-+ | +-+
| |1| +>|2| | |3|
| +-+ | +-+ | +-+
| A | A | A
| | | | | |
++--++ ++--++ ++--++
+->| Q |-->| Q |-->| Q |--+
| +----+ +----+ +----+ |
+----------------------------+
]]></artwork>
</figure>
<t>If a hash is used as a classifier, the modulus of the hash might
be used as an array index, selecting the sub-queue that the packet
will go into. One can imagine other classifiers, such as using a
Differentiated Services Code Point (DSCP) value as an index into an
array containing the queue number for a flow, or more complex access
list implementations.</t>
<t>In any event, a sub-queue contains the traffic for a flow, and
data is sent from each sub-queue in succession.</t>
</section>
<section anchor="WFQ" title="Calendar Queue Models">
<t>Another class of implementation approaches, generically referred
to as "Weighted Fair Queues" or "Calendar Queue Implementations",
implements the structure of the queue as an array or ring of
sub-queues (often called "buckets") associated with time or
sequence; Each bucket contains the set of packets, which may be
null, intended to be sent at a certain time or following the
emptying of the previous bucket. The queue structure includes a
look-aside table that indicates the current depth (which is to say,
the next bucket) of any given class of traffic, which might
similarly be identified using a hash, a DSCP, an access list, or any
other classifier. Conceptually, the queues each contain zero or more
packets from each class of traffic. One is the queue being emptied
"now"; the rest are associated with some time or sequence in the
future.</t>
<t>On enqueue, the enqueue function classifies a packet and
determines the current depth of that class, with a view to
scheduling it for transmission at some time or sequence in the
future. If the unit of scheduling is a packet and the queuing
quantum is one packet per sub-queue, a burst of packets arrives in a
given flow, and at the start the flow has no queued data, the first
packet goes into the "next" queue, the second into its successor,
and so on; if there was some data in the class, the first packet in
the burst would go into the bucket pointed to by the look-aside
table. If the unit of scheduling is time, the explanation in <xref
target="VC"/> might be simplest to follow, but the bucket selected
will be the bucket corresponding to a given transmission time in the
future. A necessary side-effect, memory being finite, is that there
exist a finite number of "future" buckets. If enough traffic arrives
to cause a class to wrap, one is forced to drop something
(tail-drop).</t>
<t>On dequeue, the buckets are searched at their stated times or in
their stated sequence, and when a bucket is identified that contains
data, removes a specified quantum of data from it and, by extension,
from the associated traffic classes. A single bucket might contain
data from a number of classes simultaneously.</t>
<?rfc needLines="25"?>
<figure anchor="wfq" title="Calendar Queue">
<artwork align="center"><![CDATA[
+-+
+>|1|
| +-+
| |
| +-+ +-+
| |2| +>|2|
| +-+ | +-+
| | | |
| +-+ | +-+ +-+
| |3| | |1| +>|1|
| +-+ | +-+ | +-+
| A | A | A
| | | | | |
++--++ ++--++ ++--++
"now"+->| Q |-->| Q |-->| Q |-->...
+----+ +----+ +----+
A A A
|3 |2 |1
+++++++++++++++++++++++
|||| Flow ||||
+++++++++++++++++++++++
]]></artwork>
</figure>
<t>In any event, a sub-queue contains the traffic for a point in
time or a point in sequence, and data is sent from each sub-queue in
succession. If sub-queues are associated with time, an interesting
end case develops: If the system is draining a given sub-queue, and
the time of the next sub-queue arrives, what should the system do?
One potentially valid line of reasoning would have it continue
delivering the data in the present queue, on the assumption that it
will likely trade off for time in the next. Another potentially
valid line of reasoning would have it discard any waiting data in
the present queue and move to the next.</t>
</section>
<section anchor="sfq"
title="Work Conserving Models and Stochastic Fairness Queuing">
<t>McKenney's <xref target="SFQ">Stochastic Fairness Queuing</xref>
is an example of a work conserving algorithm. This algorithm
measures packets, and considers a "flow" to be an equivalence class
of traffic defined by a hashing algorithm over the source and
destination IPv4 addresses. As packets arrive, the enqueue function
performs the indicated hash and places the packet into the indicated
sub-queue. The dequeue function operates as described in <xref
target="WRR"/>; sub-queues are inspected in round-robin sequence,
and if they contain one or more packets, a packet is removed.</t>
<t>Shreedhar's <xref target="DRR">Deficit Round Robin</xref> model
modifies the quanta to bytes, and deals with variable length
packets. A sub-queue descriptor contains a waiting quantum (the
amount intended to be dequeued on the previous dequeue attempt that
was not satisfied), a per-round quantum (the sub-queue is intended
to dequeue a certain number of bytes each round), and a maximum to
permit (some multiple of the MTU). In each dequeue attempt, the
dequeue method sets the waiting quantum to the smaller of the
maximum quantum and the sum of the waiting and incremental quantum.
It then dequeues up to the waiting quantum, in bytes, of packets in
the queue, and reduces the waiting quantum by the number of bytes
dequeued. Since packets will not normally be exactly the size of the
quantum, some dequeue attempts will dequeue more than others, but
they will over time average the incremental quantum per round if
there is data present.</t>
<t>McKenny or Shreedhar's models could be implemented as described
in <xref target="WFQ"/>. The weakness of a WRR approach is the
search time expended when the queuing system is relatively empty,
which the calendar queue model obviates.</t>
</section>
<section anchor="VC"
title="Non Work Conserving Models and Virtual Clock">
<t>Zhang's <xref target="VirtualClock">Virtual Clock</xref> is an
example of a non-work-conserving algorithm. It is trivially
implemented as described in <xref target="WFQ"/>. It associates
buckets with intervals in time, with durations on the order of
microseconds to tens of milliseconds. Each flow is assigned a rate
in bytes per interval. The flow entry maintains a point in time the
"next" packet in the flow should be scheduled.</t>
<t>On enqueue, the method determines whether the "next schedule"
time is "in the past"; if so, the packet is scheduled "now", and if
not, the packet is scheduled at that time. It then calculates the
new "next schedule" time, as the current "next schedule" time plus
the length of the packet divided by the rate; if the resulting time
is also in the past, the "next schedule" time is set to "now", and
otherwise to the calculated time. As noted in <xref target="WFQ"/>,
there is an interesting point regarding "too much time in the
future"; if a packet is scheduled too far into the future, it may be
marked or dropped in the AQM procedure, and if it runs beyond the
end of the queuing system, may be defensively tail dropped.</t>
<t>On dequeue, the bucket associated with the time "now" is
inspected. If it contains a packet, the packet is dequeued and
transmitted. If the bucket is empty and the time for the next bucket
has not arrived, the system waits, even if there is a packet in the
next bucket. As noted in <xref target="WFQ"/>, there is an
interesting point regarding the queue associated with "now". If a
subsequent bucket, even if it is actually empty, would be delayed by
the transmission of a packet, one could imagine marking the packet
<xref target="RFC3168">ECN CE</xref> <xref target="RFC6679"/> or
dropping the packet.</t>
</section>
</section>
</section>
<section anchor="integration" title="Queuing, Marking, and Dropping">
<t>Queuing, marking, and dropping are integrated in any system that has
a queue. If nothing else, as memory is finite, a system has to drop as
discussed in <xref target="WFQ"/> and <xref target="VC"/> in order to
protect itself. However, host transports interpret drops as signals, so
AQM algorithms use that as a mechanism to signal.</t>
<t>It is useful to think of the effects of queuing as a signal as well.
The receiver sends acknowledgements as data is received, so the arrival
of acknowledgements at the sender paces the sender at approximately the
average rate it is able to achieve through the network. This is true
even if the sender keeps an arbitrarily large amount of data stored in
network queues, and is the basis for delay-based congestion control
algorithms. So, delaying a packet momentarily in order to permit another
session to improve its operation has the effect of signaling a slightly
lower capacity to the sender.</t>
<section anchor="integration-fifo" title="Queuing with Tail Mark/Drop">
<t>In the default case, in which a FIFO queue is used with defensive
tail-drop only, the effect is therefore to signal to the sender in two
ways: <list style="symbols">
<t>Ack Clocking, pacing the sender to send at approximately the
rate it can deliver data to the receiver, and</t>
<t>Defensive loss, when a sender sends faster than available
capacity (such as by probing network capacity when fully utilizing
that capacity) and overburdens a queue.</t>
</list></t>
</section>
<section anchor="integration-codel" title="Queuing with CoDel Mark/Drop">
<t>In any case wherein a queuing algorithm is used along with <xref
target="I-D.ietf-aqm-codel">CoDel</xref>, the sequence of events is
that a packet is time-stamped, enqueued, dequeued, compared to a
subsequent reading of the clock, and then acted on, whether by
dropping it, marking and forwarding it, or simply forwarding it. This
is to say that the only drop algorithm inherent in queuing is the
defensive drop when the queue's resources are overrun. However, the
intention of marking or dropping is to signal to the sender much
earlier, when a certain amount of delay has been observed. In a
FIFO+CoDel, Virtual Clock+CoDel, or <xref
target="I-D.ietf-aqm-fq-codel">FlowQueue-Codel</xref> implementation,
the queuing algorithm is completely separate from the AQM algorithm.
Using them in series results in four signals to the sender: <list
style="symbols">
<t>Ack Clocking, pacing the sender to send at approximately the
rate it can deliver data to the receiver through a queue,</t>
<t>Lossless signaling that a certain delay threshold has been
reached, if <xref target="RFC3168">ECN</xref><xref
target="RFC6679"/> is in use,</t>
<t>Intentional signaling via loss that a certain delay threshold
has been reached, if ECN is not in use, and</t>
<t>Defensive loss, when a sender sends faster than available
capacity (such as by probing network capacity when fully utilizing
that capacity) and overburdens a queue.</t>
</list></t>
</section>
<section anchor="integration-pie"
title="Queuing with RED or PIE Mark/Drop">
<t>In any case wherein a queuing algorithm is used along
with <xref target="I-D.ietf-aqm-pie">PIE</xref>, <xref
target="RFC2309">RED</xref>, or other such algorithms, the
sequence of events is that a queue is inspected, a packet
is dropped, marked, or left unchanged, enqueued, dequeued,
compared to a subsequent reading of the clock, and then
forwarded on. This is to say that the AQM Mark/Drop Algorithm
precedes enqueue; if it has not been effective and as a
result the queue is out of resources anyway, the defensive
drop algorithm steps in, and failing that, the queue operates
in whatever way it does. Hence, in a FIFO+PIE, SFQ+PIE, or
Virtual Clock+PIE implementation, the queuing algorithm is
again completely separate from the AQM algorithm. Using
them in series results in four signals to the sender: <list
style="symbols">
<t>Ack Clocking, pacing the sender to send at approximately the
rate it can deliver data to the receiver through a queue,</t>
<t>Lossless signaling that a queue depth that corresponds to a
certain delay threshold has been reached, if ECN is in use,</t>
<t>Intentional signaling via loss that a queue depth that
corresponds to a certain delay threshold has been reached, if ECN
is not in use, and</t>
<t>Defensive loss, when a sender sends faster than available
capacity (such as by probing network capacity when fully utilizing
that capacity) and overburdens a queue.</t>
</list></t>
</section>
</section>
<section anchor="conclusion" title="Conclusion">
<t>To summarize, in <xref target="fq"/>, implementation approaches for
several classes of queueing algorithms were explored. Queuing algorithms
such as SFQ, Virtual Clock, and <xref
target="I-D.ietf-aqm-fq-codel">FlowQueue-Codel</xref> have value in the
network, in that they delay packets to enforce a rate upper bound or to
permit competing flows to compete more effectively. ECN Marking and loss
are also useful signals if used in a manner that enhances TCP/SCTP
operation or restrains unmanaged UDP data flows.</t>
<t>Conceptually, queuing algoritms and a mark/drop algorithms operate in
series, as discussed in <xref target="integration"/>, not as a single
algorithm. The observed effects differ: defensive loss protects the
intermediate system and provides a signal, AQM mark/drop works to reduce
mean latency, and the scheduling of flows works to modify flow
interleave and acknowledgement pacing. Certain features like flow
isolation are provided by fair queueing related designs, but are not the
effect of the mark/drop algorithm.</t>
<t>There is value in implementing and coupling the operation of both
queueing algorithms and queue management algorithms, and there is
definitely interesting research in this area, but specifications,
measurements, and comparisons should decouple the different algorithms
and their contributions to system behavior.</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This memo asks the IANA for no new parameters.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>This memo adds no new security issues; it observes on implementation
strategies for Diffserv implementation.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>This note grew out of, and is in response to, mailing list
discussions in AQM, in which some have pushed an algorithm the compare
to AQM marking and dropping algorithms, but which includes Flow
Queuing.</t>
</section>
</middle>
<back>
<!-- references split to informative and normative -->
<references title="Normative References">
<?rfc include="reference.RFC.2475" ?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.3390" ?>
<?rfc include="reference.RFC.5690" ?>
<?rfc include="reference.RFC.6928" ?>
<?rfc include="reference.I-D.ietf-aqm-codel" ?>
<?rfc include="reference.I-D.ietf-aqm-fq-codel" ?>
<?rfc include="reference.I-D.ietf-aqm-pie" ?>
<?rfc include="reference.RFC.0970" ?>
<?rfc include="reference.RFC.2309" ?>
<?rfc include="reference.RFC.2990" ?>
<?rfc include="reference.RFC.3168"?>
<?rfc include="reference.RFC.6057" ?>
<?rfc include="reference.RFC.6679" ?>
<?rfc include="reference.RFC.7141" ?>
<reference anchor="VirtualClock"
target="http://www.cs.ucla.edu/~lixia/papers/90sigcomm.pdf">
<front>
<title>Virtual Clock</title>
<author fullname="Lixia Zhang">
<organization>Xerox PARC</organization>
</author>
<date month="September" year="1990"/>
</front>
<seriesInfo name="ACM SIGCOMM" value="1990"/>
</reference>
<reference anchor="DRR"
target="http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=502236">
<front>
<title>Efficient fair queueing using deficit round robin</title>
<author fullname="M. Shreedhar">
<organization>Microsoft Corporation</organization>
</author>
<author fullname="George Varghese">
<organization>Washington University in St. Louis</organization>
</author>
<date month="October" year="1995"/>
</front>
<seriesInfo name="ACM SIGCOMM" value="1995"/>
</reference>
<reference anchor="NoFair"
target="http://dl.acm.org/citation.cfm?id=1232926">
<front>
<title>Flow rate fairness: dismantling a religion</title>
<author fullname="Briscoe">
<organization>British Telecom</organization>
</author>
<date month="April" year="2007"/>
</front>
<seriesInfo name="ACM SIGCOMM" value="2007"/>
</reference>
<reference anchor="GPS"
target="http://blizzard.cs.uwaterloo.ca/keshav/home/Papers/data/89/fq.pdf">
<front>
<title>Analysis and simulation of a fair queueing algorithm</title>
<author fullname="Demers">
<organization>Xerox PARC</organization>
</author>
<author fullname="Keshav">
<organization>University of California, Berkeley</organization>
</author>
<author fullname="Scott Shenker">
<organization>Xerox PARC</organization>
</author>
<date month="September" year="1989"/>
</front>
<seriesInfo name="ACM SIGCOMM" value="1989"/>
</reference>
<reference anchor="SFQ"
target="http://www2.rdrop.com/~paulmck/scalability/paper/sfq.2002.06.04.pdf">
<front>
<title>Stochastic Fairness Queuing</title>
<author fullname="Paul E. Mckenney">
<organization>SRI International</organization>
</author>
<date month="June" year="1990"/>
</front>
<seriesInfo name="IEEE Infocom" value="1990"/>
</reference>
</references>
<section anchor="log" title="Change Log">
<t><list style="hanging">
<t hangText="Initial Version:">June 2014</t>
</list></t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 05:27:52 |