Posts tagged cbwfq
ONT Notes – Congestion Avoidance, Policing, Shaping, and Link Efficiency
Feb 2nd
- Tail drop drawbacks
- TCP synchronization – Dropping TCP packets from different flows can cause them all to window down and back up again at the same time in cycles.
- TCP starvation – Non-TCP or aggressive flows can starve everyone else out when TCP throttles back.
- No differentiated drop – Tail drop doesn’t care who you are, so you get dropped if the queue is full.
- RED – Random Early Detection
- Avoids tail drop by randomly dropping packets from the queue before it gets full
- Only dropped TCP flows slow down instead of everyone who has sent a packet since the queue filled
- Queues are smaller.
- Link utilization is more efficient
- Configured with
- Minimum threshold – start dropping when the queue is this size
- Maximum threshold – if the queue is this big, start tail dropping
- Mark probability denominator (MPD) – 1/MPD is the ratio of packets to drop when between the thresholds
- WRED – Weighted RED
- Based on IP precedence or DSCP values
- Less-important packets are dropped more aggressively than important packets
- Applied to an interface, VC or a class within a policy map
- CBWRED – Class based WRED
- Configured with CBWFQ
- Policing
- Limits subrate bandwidth (give you 100kbps on a T1)
- Limits traffic of certain applications
- Any traffic that exceeds police is dropped or re-classified; it’s a hard limit
- Inbound or outbound
- Shaping
- Sets a limit but buffers any in excess
- Requires memory to store the buffer
- Buffers = delay and/or jitter
- Outbound only
- Can respond to network signals like BECNs and FECNs
- Token and bucket
- The queue is a bucket; if a byte of data needs to be sent, it needs a token.
- If there are enough tokens, the traffic is considered conforming.
- If there aren’t enough tokens, the traffic is considered exceeding, which triggers the drop (policing), re-classify (policing), or buffer (shaping).
- Frame relay traffic shaping (FRTS)
- Only controls frame relay traffic
- Applied on subif or DLCI
- Support fragmentation and interleaving
- Reacts to FECNs and BECNs
- Compression
- Removed redundancy and patterns in data
- Less data = less latency
- Hardware compression or hardware-assisted compression does not involve the main CPU
- Software compression does
- Payload compression
- Header compression
- Link fragmentation and interleaving
- Small data might be waiting for larger data pieces to finish sending
- Chunks data into smaller fragments so they don’t have to wait
- Interleaving shuffles flows in the Tx queue
ONT Notes – Queuing
Jan 23rd
Here are some more notes from my studies. Of course, no one cares about them but me, but it’s my blog. I’m sure someone will find it useful. Please help to correct dumbass mistakes.
- Congestion
- Speed mismatch – traffic leaves a lower-bandwidth interface than the one it came in on
- Aggregation problem – lots of links with one egress of equal bandwidth
- Confluence problem – a bunch of traffic needs to egress out of the same interface
- Queuing
- Transmit queue (TxQ) – hardware queue; there’s only one you can’t touch
- Software queue – where packets wait to be sent; there are many queue-types that you modified to police traffic
- FIFO
- If I beat you to the router, I leave the router first.
- Possible long delays, jitter, and starvation
- Priority queuing (PQ)
- Four queues
- High-priority
- Medium-priority
- Normal-priority
- Low-priority
- Scheduler starts from high and work to low
- When the high queue is empty, it processes a packet from medium, then starts all over
- Can you say starvation?
- Four queues
- Round robin queuing (RR)
- One packet from this queue, one from the next, etc., then start over again
- Custom queuing (CQ)
- Weighted round robin
- Queues are given weights (bandwidth guarantees)
- Weighted Fair Queuing (WFQ)
- Default queuing on slow links ( < E1 )
- Divides traffic into flows
- Equal bandwidth is given to each flow
- Provides faster scheduling to low-volume flows
- Provides more bandwidth to higher-priority flows
- Flows identified by a hash
- Source IP
- Destination IP
- Protocol number
- ToS
- Source port
- Destination port
- Each unique has is a new flow
- No way to allocate bandwidth among the flows
- By default, up to 256 queues are made, but that is changeable to a power of 2 between 16 and 4096
- If the max number of flows is reached, queues are reused for other flows
- If a queue is full, a packet may be dropped.
- WFQ early dropping drops packets when the queue reaches the congestive discard threshold (CDT)
- Advantages
- Simple configuration
- No starvation
- Guarantee processing of all flows
- Drops packets from big-hitter flows
- Faster service no low-hitters (interactive) flows
- Standard on (nearly) all IOS devices
- Disadvantages
- Classification and scheduling are not configurable
- Only on slow links
- No guarantee of bandwidth or delay
- Class-based Weighted Fair Queuing (CBWFQ)
- User-defined queues for flexibility
- Configured with class-maps via MQC
- Weights are calculated based on values give in class-map
- Bandwidth – guarantee this much bandwidth
- Bandwidth percent – give me this much of the available bandwidth
- Bandwidth remaining percent
- Advantages
- User-defined traffic classes
- Each queue gets its own bandwidth
- Scalability
- Disadvantages
- No delay guarantee (not good for real-time application like voice)
- Configuring
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
- Low-latency Queuing
- Includes strict priority queue for delay-sensitive data
- Strict priority queue is policed to avoid starvation of other queues
- Configured the same way as normal CBWFQ, but with the priority keyword
- This configuration makes TESTCM2 a priority queue
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