Networks Horizon

share

Sunday 8 April 2012

Quality of Service (QoS)-Part7
Congestion Avoidance -WRED

Tail drop-Consequences

We need to first understand crises of Tail drop. Tail Drop is how we handle out routing for decades. We had packet streams coming into the router and router used to manage them as it could because routers is made to bridge discontinues networks. Lot of time this network also present some speed mismatch when we are going from much faster segment like LAN connection to slower segment like WAN. 

Now, the crisis of trail drop comes in with the basic question-how the TCP works?.  In TCP, In case of data transfer, a device begins to use a system called windowing. It initially going to send one packet and as soon as that packet gets acknowledge reliably, window size continues to grow until it eventually reaches to a level where link is completely utilized. Once link is over-utilize, packets starts getting dropped. Once there is failure acknowledgement and packet starts getting dropped,  TCP mechanism reduces its window size by half.  This is called Tail Drop.

After some time, same thing happens and traffic slowly picks up and goes to the same level and then drops again. This happens repeatedly and when another device tries to send the data in this situation, it synchronize its window size accordingly. Traffic from second device behaves almost same though allocated bandwidth for second application is not yet over-utilized. With this process, we have gaps where bandwidth remain un-utilized during the moment where window size is dropped (at low level). When all the application running on the system behaves the same way and follow the same pattern, its become a global problem and now called global synchronisation.

This is how TCP system has been working for decades and resulting improper utilization and global synchronization problem due to its TCP tail drop feature.

Consequences of TCP Tail Drop Problem:
  • Global Synchronization and non-utilized networks
  • Traffic starvation
  • Unbiased Dropping
Random Early Detection(RED)

To overcome this problem of Tail Drop, RED technique was devoloped. It has below features: 
  • Randomly drops packets from TCP flows to minimize Synchronization and helps in utilizing whole bandwidth properly. So It is nothing but sacrificing few TCP packet for the sake of rest of the network.
  • Dropping of RED becomes more aggressive as Queues start filling in and reaches maximum available bandwidth limit.
Limitation of RED: works only in case of TCP where window size has an impact on end to end packet delivery.

Weighted Random Early Detection (WRED)

WRED is a Cisco's implementation of RED allows multiple RED profiles in :
IP Precedence (8 Profiles)
DSCP (64 profiles)

HOW WRED works:

When traffic stream reaches up-to minimum threshold and crosses, traffic begins to drop on some ratio based on MPD. Once traffic crosses the maximum threshold, whole traffic which is exceeding starts getting dropped.

So minimum threshold is where, IP packets start getting dropped. Maximum Threshold is where whole traffic above this threshold is dropped.

Mark Probability Denominator (MPD) is number of packets from which 1 packet will be dropped. If we say MPD: 100, it means 1 packet out of 100 packets will be dropped when traffic crosses minimum threshold.

Terms:
MPD=Mark Probability Denominator
Maximum Threshold
Minimum Threshold

We can make WRED work in different classes of traffic. For example, we can set different Minimum/Maximum Threshold and MPD values based on class priority for different classes.

See below picture:

for IP Prec 1, we want to start dropping when minimum threshold is 10 means 10 packets are in queue. Similarly for IP Prec 2, we want to start dropping when there are 15 packets in the queue.

Dropping of packet will be based on MPD value defined. After maximum threshold all the packets in the queue will be dropped which are crossing maximum threshold.

Config example:

R3 (config)#policy-map WRED1
R3 (config-pmap)#class Match_FTP
R3 (config-pmap-c)#random-detect?
dscp
dscp-based
ecn
prec-based
precedence
R3 (config-pmap-c)#random-detect dscp-based

If we want to use cisco recommended WRED config, we need to configure dscp-based or prec-based based on dscp and IP Precedence marking
If we need to tweek the WRED config, we can configure like below:

R3 (config-pmap-c)#random-detect dscp af11 <min_threshold> <maximum_threshold> <mpd>

Explicity Congestion Notification (ECN)

It does make WRED a little proactive in essences that it is going to try to tell the sender to slow down instead of dropping packet at random.It uses last two bits of ToS bytes in IP packet for the purpose. These two bits are called ECN bits. Cisco router can mark these bits on one of these four marking as given below:
  • 00-Non ECN-capable
  • 01-Endpoints are ECN Capable (nothing else to be done)
  • 10-Endpoints are ECN Capable (nothing else to be done)
  • 11-Congestion Experienced (tells sending device to slow down)


ECN to work perfectly, routers and sending devices (PCs, phone) both should be ECN compatible. Sending router sends ECN bits 11 to other end router.  Receiving router sends ECN-ECHO back to the sending device in the response. Once sending device receives the ECH-ECHO, it slows down the sending.

Config:

R3 (config-pmap-c)#random-detect ecn

Before this configuration to work perfectly, devices should be ECN compatible. Whenever congestion is notified, ECN bits(11) stating congestion Experienced are sent.

No comments:

Post a Comment