<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Aaron&#039;s Worthless Words &#187; wfq</title>
	<atom:link href="http://aconaway.com/tag/wfq/feed/" rel="self" type="application/rss+xml" />
	<link>http://aconaway.com</link>
	<description>Not something you want to hear</description>
	<lastBuildDate>Wed, 08 Sep 2010 14:39:15 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0.1</generator>
		<item>
		<title>ONT Notes &#8211; Congestion Avoidance, Policing, Shaping, and Link Efficiency</title>
		<link>http://aconaway.com/2010/02/02/ont-notes-congestion-avoidance-policing-shaping-and-link-efficiency/</link>
		<comments>http://aconaway.com/2010/02/02/ont-notes-congestion-avoidance-policing-shaping-and-link-efficiency/#comments</comments>
		<pubDate>Wed, 03 Feb 2010 03:09:47 +0000</pubDate>
		<dc:creator>Aaron Conaway</dc:creator>
				<category><![CDATA[ccnp]]></category>
		<category><![CDATA[ont]]></category>
		<category><![CDATA[642-845]]></category>
		<category><![CDATA[bucket]]></category>
		<category><![CDATA[cbwfq]]></category>
		<category><![CDATA[cbwred]]></category>
		<category><![CDATA[certification]]></category>
		<category><![CDATA[cisco]]></category>
		<category><![CDATA[class]]></category>
		<category><![CDATA[compression]]></category>
		<category><![CDATA[fifo]]></category>
		<category><![CDATA[fragmentation]]></category>
		<category><![CDATA[interleaving]]></category>
		<category><![CDATA[policing]]></category>
		<category><![CDATA[policy]]></category>
		<category><![CDATA[qos]]></category>
		<category><![CDATA[queueing]]></category>
		<category><![CDATA[queuing]]></category>
		<category><![CDATA[red]]></category>
		<category><![CDATA[shaping]]></category>
		<category><![CDATA[tail drop]]></category>
		<category><![CDATA[test]]></category>
		<category><![CDATA[token]]></category>
		<category><![CDATA[voice]]></category>
		<category><![CDATA[voip]]></category>
		<category><![CDATA[wfq]]></category>
		<category><![CDATA[wred]]></category>

		<guid isPermaLink="false">http://aconaway.com/?p=477</guid>
		<description><![CDATA[Here's another set of notes from my ONT studies.]]></description>
			<content:encoded><![CDATA[<ul>
<li>Tail drop drawbacks
<ul>
<li>TCP synchronization &#8211; Dropping TCP packets from different flows can cause them all to window down and back up again at the same time in cycles.</li>
<li>TCP starvation &#8211; Non-TCP or aggressive flows can starve everyone else out when TCP throttles back.</li>
<li>No differentiated drop &#8211; Tail drop doesn&#8217;t care who you are, so you get dropped if the queue is full.</li>
</ul>
</li>
<li>RED &#8211; Random Early Detection
<ul>
<li>Avoids tail drop by randomly dropping packets from the queue before it gets full</li>
<li>Only dropped TCP flows slow down instead of everyone who has sent a packet since the queue filled</li>
<li>Queues are smaller.</li>
<li>Link utilization is more efficient</li>
<li>Configured with
<ul>
<li>Minimum threshold &#8211; start dropping when the queue is this size</li>
<li>Maximum threshold &#8211; if the queue is this big, start tail dropping</li>
<li>Mark probability denominator (MPD) &#8211; 1/MPD is the ratio of packets to drop when between the thresholds</li>
</ul>
</li>
</ul>
</li>
<li>WRED &#8211; Weighted RED
<ul>
<li>Based on IP precedence or DSCP values</li>
<li>Less-important packets are dropped more aggressively than important packets</li>
<li>Applied to an interface, VC or a class within a policy map</li>
</ul>
</li>
<li>CBWRED &#8211; Class based WRED
<ul>
<li>Configured with CBWFQ</li>
</ul>
</li>
<li>Policing
<ul>
<li>Limits subrate bandwidth (give you 100kbps on a T1)</li>
<li>Limits traffic of certain applications</li>
<li>Any traffic that exceeds police is dropped or re-classified; it&#8217;s a hard limit</li>
<li>Inbound or outbound</li>
</ul>
</li>
<li>Shaping
<ul>
<li>Sets a limit but buffers any in excess</li>
<li>Requires memory to store the buffer</li>
<li>Buffers = delay and/or jitter</li>
<li>Outbound only</li>
<li>Can respond to network signals like BECNs and FECNs</li>
</ul>
</li>
<li>Token and bucket
<ul>
<li>The queue is a bucket; if a byte of data needs to be sent, it needs a token.</li>
<li>If there are enough tokens, the traffic is considered conforming.</li>
<li>If there aren&#8217;t enough tokens, the traffic is considered exceeding, which triggers the drop (policing), re-classify (policing), or buffer (shaping).</li>
</ul>
</li>
<li>Frame relay traffic shaping (FRTS)
<ul>
<li>Only controls frame relay traffic</li>
<li>Applied on subif or DLCI</li>
<li>Support fragmentation and interleaving</li>
<li>Reacts to FECNs and BECNs</li>
</ul>
</li>
<li>Compression
<ul>
<li>Removed redundancy and patterns in data</li>
<li>Less data = less latency</li>
<li>Hardware compression or hardware-assisted compression does not involve the main CPU</li>
<li>Software compression does</li>
<li>Payload compression</li>
<li>Header compression</li>
</ul>
</li>
<li>Link fragmentation and interleaving
<ul>
<li>Small data might be waiting for larger data pieces to finish sending</li>
<li>Chunks data into smaller fragments so they don&#8217;t have to wait</li>
<li>Interleaving shuffles flows in the Tx queue</li>
</ul>
</li>
</ul>]]></content:encoded>
			<wfw:commentRss>http://aconaway.com/2010/02/02/ont-notes-congestion-avoidance-policing-shaping-and-link-efficiency/feed/</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
		<item>
		<title>ONT Notes &#8211; Queuing</title>
		<link>http://aconaway.com/2010/01/23/ont-notes-queuing/</link>
		<comments>http://aconaway.com/2010/01/23/ont-notes-queuing/#comments</comments>
		<pubDate>Sun, 24 Jan 2010 04:22:06 +0000</pubDate>
		<dc:creator>Aaron Conaway</dc:creator>
				<category><![CDATA[Uncategorized]]></category>
		<category><![CDATA[642-845]]></category>
		<category><![CDATA[cbwfq]]></category>
		<category><![CDATA[ccnp]]></category>
		<category><![CDATA[certification]]></category>
		<category><![CDATA[cisco]]></category>
		<category><![CDATA[classification]]></category>
		<category><![CDATA[diffserv]]></category>
		<category><![CDATA[fifo]]></category>
		<category><![CDATA[llq]]></category>
		<category><![CDATA[marking]]></category>
		<category><![CDATA[ont]]></category>
		<category><![CDATA[policing]]></category>
		<category><![CDATA[pq]]></category>
		<category><![CDATA[qos]]></category>
		<category><![CDATA[queueing]]></category>
		<category><![CDATA[queuing]]></category>
		<category><![CDATA[round robin]]></category>
		<category><![CDATA[test]]></category>
		<category><![CDATA[voice]]></category>
		<category><![CDATA[voip]]></category>
		<category><![CDATA[wfq]]></category>

		<guid isPermaLink="false">http://aconaway.com/?p=452</guid>
		<description><![CDATA[Here are some more notes from my studies.  Of course, no one cares about them but me, but it&#8217;s my blog.  I’m sure someone will find it useful.  Please help to correct dumbass mistakes. Congestion Speed mismatch &#8211; traffic leaves a lower-bandwidth interface than the one it came in on Aggregation problem &#8211; lots of [...]]]></description>
			<content:encoded><![CDATA[<p>Here are some more notes from my studies.  Of course, no one cares about them but me, but it&#8217;s my blog.  I’m sure someone will find it useful.  Please help to correct dumbass mistakes.</p>
<ul>
<li>Congestion
<ul>
<li>Speed mismatch &#8211; traffic leaves a lower-bandwidth interface than the one it came in on</li>
<li>Aggregation problem &#8211; lots of links with one egress of equal bandwidth</li>
<li>Confluence problem &#8211; a bunch of traffic needs to egress out of the same interface</li>
</ul>
</li>
<li>Queuing
<ul>
<li>Transmit queue (TxQ) &#8211; hardware queue; there&#8217;s only one you can&#8217;t touch</li>
<li>Software queue &#8211; where packets wait to be sent; there are many queue-types that you modified to police traffic</li>
</ul>
</li>
<li>FIFO
<ul>
<li>If I beat you to the router, I leave the router first.</li>
<li>Possible long delays, jitter, and starvation</li>
</ul>
</li>
<li>Priority queuing (PQ)
<ul>
<li>Four queues
<ul>
<li>High-priority</li>
<li>Medium-priority</li>
<li>Normal-priority</li>
<li>Low-priority</li>
</ul>
</li>
<li>Scheduler starts from high and work to low</li>
<li>When the high queue is empty, it processes a packet from medium, then starts all over</li>
<li>Can you say starvation?</li>
</ul>
</li>
<li>Round robin queuing (RR)
<ul>
<li>One packet from this queue, one from the next, etc., then start over again</li>
</ul>
</li>
<li>Custom queuing (CQ)
<ul>
<li>Weighted round robin</li>
<li>Queues are given weights (bandwidth guarantees)</li>
</ul>
</li>
<li>Weighted Fair Queuing (WFQ)
<ul>
<li>Default queuing on slow links ( &lt; E1 )</li>
<li>Divides traffic into flows</li>
<li>Equal bandwidth is given to each flow</li>
<li>Provides faster scheduling to low-volume flows</li>
<li>Provides more bandwidth to higher-priority flows</li>
<li>Flows identified by a hash
<ul>
<li>Source IP</li>
<li>Destination IP</li>
<li>Protocol number</li>
<li>ToS</li>
<li>Source port</li>
<li>Destination port</li>
</ul>
</li>
<li>Each unique has is a new flow</li>
<li>No way to allocate bandwidth among the flows</li>
<li>By default, up to 256 queues are made, but that is changeable to a power of 2 between 16 and 4096</li>
<li>If the max number of flows is reached, queues are reused for other flows</li>
<li>If a queue is full, a packet may be dropped.</li>
<li>WFQ early dropping drops packets when the queue reaches the congestive discard threshold (CDT)</li>
<li>Advantages
<ul>
<li>Simple configuration</li>
<li>No starvation</li>
<li>Guarantee processing of all flows</li>
<li>Drops packets from big-hitter flows</li>
<li>Faster service no low-hitters (interactive) flows</li>
<li>Standard on (nearly) all IOS devices</li>
</ul>
</li>
<li>Disadvantages
<ul>
<li>Classification and scheduling are not configurable</li>
<li>Only on slow links</li>
<li>No guarantee of bandwidth or delay</li>
</ul>
</li>
</ul>
</li>
<li>Class-based Weighted Fair Queuing (CBWFQ)
<ul>
<li>User-defined queues for flexibility</li>
<li>Configured with class-maps via MQC</li>
<li>Weights are calculated based on values give in class-map
<ul>
<li>Bandwidth &#8211; guarantee this much bandwidth</li>
<li>Bandwidth percent &#8211; give me this much of the available bandwidth</li>
<li>Bandwidth remaining percent</li>
</ul>
</li>
<li>Advantages
<ul>
<li>User-defined traffic classes</li>
<li>Each queue gets its own bandwidth</li>
<li>Scalability</li>
</ul>
</li>
<li>Disadvantages
<ul>
<li>No delay guarantee (not good for real-time application like voice)</li>
</ul>
</li>
<li>Configuring
<ul>
<blockquote>
<pre>class-map TESTCM1
 match access-group 100
!
class-map TESTCM2
 match access-group 200
!
policy-map TESTPM
 class TESTCM1
  bandwidth 64
 class TESTCM2
  bandwidth 128</pre>
</blockquote>
</ul>
</li>
</ul>
</li>
<li>Low-latency Queuing
<ul>
<li>Includes strict priority queue for delay-sensitive data</li>
<li>Strict priority queue is policed to avoid starvation of other queues</li>
<li>Configured the same way as normal CBWFQ, but with the <em>priority</em> keyword</li>
<li>This configuration makes <em>TESTCM2</em> a priority queue</li>
<blockquote>
<pre>class-map TESTCM1
 match access-group 100
!
class-map TESTCM2
 match access-group 200
!
policy-map TESTPM
 class TESTCM1
  bandwidth 64
 class TESTCM2
  priority bandwidth 128</pre>
</blockquote>
</ul>
</li>
</ul>]]></content:encoded>
			<wfw:commentRss>http://aconaway.com/2010/01/23/ont-notes-queuing/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>
