<?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; bucket</title>
	<atom:link href="http://aconaway.com/tag/bucket/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>
	</channel>
</rss>
