Case Study:Router Interface Congestion<?XML:NAMESPACE PREFIX = O />

当router接口的外出队列满的时候

1>以后进来的packets都被drop

2>packets的丢弃可能会导致严重的应用性能的衰减

3>默认,router进行tail dropping(尾丢弃)

4>如果配置了WFQ,就可以使用更加智能化的dropping scheme

 

 

Case Study:Tail-Drop Flaws(缺点)

1>TCP synchronization

2>TCP starvation(饿死)

3>High delay and jitter

4>No differentiated drop

5>Poor feedback to TCP

 

TCP Synchronization:
TCP Starvation,Delay,and Jitter:
 
Delay:一个长的队列导致packets排队很长时间,进行导致delay

Starve(饿死):多个aggressive flows长时间的占用队列,使后边的包不能发送,即starve.

Jitter:传送的速度一会快一会慢.buffer不断的变化.

 

 

Conclusion:

Tail dropping这种丢弃机制应该避免.

实现的方法是:

在接口接近congestion时就开始丢弃packets,从而降低TCP会话的速率.因为TCP流量占总的internet的流量的80%,它的速率的降低也就意味着congestion的减少,从而可以不使用tail dropping.

 

 

Case Study:Random Early Detection(RED)

RED是在队列满之前就开始随机的丢弃packets的机制.

RED丢弃packets的概率会越来越大

RED优点:

1>使TCP会话速率降到匹配输出链路带宽

2>使平均的队列大小比最大队列长度小得多

 

RED Profile:

Before RED:

After RED:

Case Study:Weighted Random Early Detection

WRED对每一个wight使用不同的RED原型.

每一个RED原型使用以下三个值来标识:

1>Minimum threshold

2>Maximum threshold

3>Maximum drop probability

Weight可以是:

1>Ip precedence(支持8个RED原型)

2>DSCP(支持64个RED原型)

 

WRED丢弃更多的不重要的packets,即weight值低的.

 

WRED Profiles:

IP Precedence and Class Selector Profiles:

1>当平均队列大小>20时,IP优先级为0的包就开始被丢弃了

2>当平均队列大小>22时,IP优先级为1的包就开始被丢弃了

................

3>当平均队列大小>35时,IP优先级为7的包就开始被丢弃了

4>当平均队列大小>37时,RSVP流开始被丢弃了

5>当平均队列大小>40时, 所有包就都被丢弃

 

 

DSCP-Based WRED(Expedited Forwarding,加速转发):

DSCP-Based WRED(Assured Forwarding,保证转发):

WRED Building Blocks:

最后一步,WRED还要反馈一下平均的队列长度,因为在指定minimum threshold,maximum threshold时都是平均队列长度为单位的threshold阈(值).

 

WRED and DWRED Configuration:

Router(config-if)#random-detect  {prec-based | dscp-based}

1>默认启用基于IP优先级的WRED,prec-based

2>默认的WRED原型被使用

3>Nondistributed WRED不能与fancy queueing(高级队列)一同使用,而只能使用FIFO队列.

4>WRED可以分布式的运行于VIP-based(Versatile Interface Processor,通用接口处理器,只有高端的设备才有)接口,这就是DWRED(分布式WRED).类似于dCEF.

5>DWRED可以与DWFQ一同使用.

 

Changing the WRED Profile:

Router(config-if)#random-detect precedence {precedence} {min-threshold} {max-threshold} {mark-prob-denominator}

改变特定的IP优先级的WRED原型

Min-threshold和max-threshold都是平均队列大小为单位的threshold阈(值)

最大丢弃概率(maximum drop probability): 1/mark-prob-denominator

配置命令中的mark-prob-denominator是上述公式中的分母,它用来计算出最大丢弃概率

将所有的IP优先级的RED原型都配置成相同的,就可以将WRED变为RED.

 

 

Changing WRED Sensitivity to Bursts:

Router(config-if)#random-detect exponential-weighting-constant {n}

Exponential-weighting-constant:指数权重常量

 

WRED使用平均队列大小决定当前的WRED mode(no drop,ramdom drop,full drop)

一个高的N值允许一个short bursts:

当n很大时,计算出来的新的平均队列大小就比较小,进而越远离于maximum-threshold,所以它的ramdom-drop范围可以很大,而不至于到full-drop,即可突发量比较大.

一个低的N值使WRED对bursts更加敏感,不允许几乎很小的bursts

同样,当n很小时,计算出来的新的平均队列大小就比较大,进而越接近maximum-threshold,所以它的ramdom-drop范围就会比较小,即可突发量比较小.

N值默认为9,则新的平均队列大小为:
这个命令最终实现的是改变计算最新的平均队列大小

 

 

Configuring DSCP-Based WRED:

Router(config-if)#random-detect {prec-based | dscp-based}

选择WRED mode,默认为Precedence-based WRED

DSCP-based WRED使用64个profiles

 

Changing the WRED Profile:

Router(config-if)#random-detect dscp {dscp} {min-threshold} {max-threshold} {mark-prob-denominator}

改变特定DSCP值的RED原型

Mark-prob-denominator为最大丢弃概率的公式分母

最大丢弃概率=1/mark-prob-denominator

 

WRED Case Study:

WRED Configuration:

1>开启WRED默认配置

2>微调WRED配置

!

Interface serial 0/1/0    注:此处使用了VIP

 Ip address 200.200.14.250 255.255.255.252

 Random-detect

 Random-detect precedence 0 10 25 10

 Random-detect precedence 1 20 35 10

 Random-detect precedence 2 15 25 10

 Random-detect precedence 3 25 35 10

 Random-detect precedence 4 1 2 1

 Random-detect precedence 5 35 40 10

 Random-detect precedence 6 30 40 10

 Random-detect precedence 7 30 40 10

!

 

WRED Monitoring:

Show interface

显示当前使用的队列/丢弃机制

显示WRED参数(VIP only)

Show queueing

显示每个接口的RED原型
Show queue

显示接口的外出队列

 

Show interface random-detect

显示RED统计信息(VIP only)

WRED Caveats(警告) and Restrictions:

1>因为相同的策略被应用到所有的flows上,一个单一的nonadaptive flow可能会垄断整个接口的buffer资源

2>当TCP占据80%的流量时,WRED是合适的

3>对非TCP流量只能进行速率限制

4>Non-distributed WRED不能与PQ,CQ及WFQ兼容实现

 

 

 

Case Study:Flow-based Weighted Random Early Detection

1>RED对所有数据流一视同仁,不区分的丢弃.

2>WRED根据不同的优先级来区分packets,但它不能区分不同的数据流的packets

3>Aggressive flows可能会垄断整个队列,进而使用其它的flows饿死.如当一个优先级很高的aggresive flows占据着队列,其它的flows只能被饿死.

4>Flow-based WRED用于追踪数据流,与WRED的追踪优先级不同.

4>Flow-based WRED优先丢弃aggressive flows.

 

Types of Flows:

Robust flows:数据流能通过降低速率来适应packets的丢失.(WRED对这种流很有效)

Fragile flows(脆弱的流):不能适应packets的丢失,占用buffer比较小.(WRED不应该被使用)

Nonadaptive flows:不能适应packet的丢失(WRED对这种流的处理效率很低),高的,持续的buffer占用.

 

Flow-Based WRED Objective:

Flow-Based WRED对于上述三种不同的活动流分配了不同的丢弃速率:

1>Robust:正常的丢弃速率

2>Fragile:非常少的丢弃速率

3>Nonadaptive:非常高的丢弃速率

 

Flow-Based WRED Building Blocks:
 
Flow-Based WRED Configuration:

Router(config-if)#random detect flow

IOS 12.0(3)T以后的版本支持此命令

在特定接口上配置实现flow-based weighted random early detectoin

在VIP-based接口上取消distirbuted WRED

取消所有的队列,转为FIFO队列.

 

Tuning Flow-Based WRED:

Router(config-if)#random-detect flow average-depth-factor {scaling factor}

指定scaling factor值,用于从平均per-flow队列大小计算最大 per-flow 队列大小.

默认为4

 

Router(config-if)#random-detect flow count {number}

指定Flow-based WRED最多追踪多少数据流

默认为256

 

 

Flow-Based WRED Monitoring:

标准的WRED命令:

Show interface

Show queueing

Show queue

Show interfaces random-detect

显示flow参数:

Show queueing ramdom-detect

 

Benefits of Flow-Based WRED:

1>原来WED处理是根据优先级的,因为一个flow可以有多个不同的优先级,它们又是同时发送的,你能够丢弃一些优先级低的packets,但flow的其它packets还在,它们从整休上看还是aggressive flow.

2>Flow-Based WRED是根据flow来处理的,如果这个flow是aggressive的,则Flow-based WRED会将整个flow丢弃,而不只是其中某些packets.

3>阻止一个单一的数据流垄断整个接口buffer资源.

4>Flow-based WRED惩罚aggressive UPD flows.

 

 

Drawbacks of Flow-based WRED:

1>Flow-based WRED不是分布式的

2>只能与FIFO队列一同使用

3>可预测性差