avatar
u*v
2
俺对QoS研究很少,我想至少在MPLS TE有用,对进来的Traffic进行分类,确认打什么标
签,走哪条路经,以后就是标记交换了,所以必须在进MPLS时就打上tag。
avatar
z*r
3
MPLW EXP bits都是在做mpls imposition的时候,要么从cos bits,要么从ip
precedence要么从dscp copy 过去的,当然也可以人工set,但是都是发生在ingress
traffic已经进到了router以后。当然俺说的这个市ip2mpls,在做swap的时候,也可以
classify based on exp bits,但是对于ingress qos来说,只是classification的不同
,并没有对queueing产生
任何影响



【在 u*v 的大作中提到】
: 俺对QoS研究很少,我想至少在MPLS TE有用,对进来的Traffic进行分类,确认打什么标
: 签,走哪条路经,以后就是标记交换了,所以必须在进MPLS时就打上tag。

avatar
u*v
4
俺对QoS研究很少,我想至少在MPLS TE有用,对进来的Traffic进行分类,确认打什么标
签,走哪条路经,以后就是标记交换了,所以必须在进MPLS时就打上tag。
avatar
c*a
5
just a guess,
1. backplane (fabric oversubscription?)
2. resource contention when 2+ inbound if competing same outbound if
other than interface ingress/egress qos, some products do fabric qos




【在 z**r 的大作中提到】
: MPLW EXP bits都是在做mpls imposition的时候,要么从cos bits,要么从ip
: precedence要么从dscp copy 过去的,当然也可以人工set,但是都是发生在ingress
: traffic已经进到了router以后。当然俺说的这个市ip2mpls,在做swap的时候,也可以
: classify based on exp bits,但是对于ingress qos来说,只是classification的不同
: ,并没有对queueing产生
: 任何影响
:
: 标

avatar
L*t
6
My guess is ingress traffic can be put into queues of different priorities.
The queue of absolute priority is of course taken care of faster than others,
thus low latency.




【在 z**r 的大作中提到】
: MPLW EXP bits都是在做mpls imposition的时候,要么从cos bits,要么从ip
: precedence要么从dscp copy 过去的,当然也可以人工set,但是都是发生在ingress
: traffic已经进到了router以后。当然俺说的这个市ip2mpls,在做swap的时候,也可以
: classify based on exp bits,但是对于ingress qos来说,只是classification的不同
: ,并没有对queueing产生
: 任何影响
:
: 标

avatar
z*r
7
俺好像突然明白了些,即使interface没有oversubscribe,那么相应的policy中的某一个
class还是有可能oversubscribed的,恰好这个class是一个高级别的queue,就体现出
ingress qos的必要了



【在 z**r 的大作中提到】
: MPLW EXP bits都是在做mpls imposition的时候,要么从cos bits,要么从ip
: precedence要么从dscp copy 过去的,当然也可以人工set,但是都是发生在ingress
: traffic已经进到了router以后。当然俺说的这个市ip2mpls,在做swap的时候,也可以
: classify based on exp bits,但是对于ingress qos来说,只是classification的不同
: ,并没有对queueing产生
: 任何影响
:
: 标

avatar
z*r
8
俺好像突然明白了些,即使interface没有oversubscribe,那么相应的policy中的某一个
class还是有可能oversubscribed的,恰好这个class是一个高级别的queue,就体现出
ingress qos的必要了



【在 z**r 的大作中提到】
: 俺好像突然明白了些,即使interface没有oversubscribe,那么相应的policy中的某一个
: class还是有可能oversubscribed的,恰好这个class是一个高级别的queue,就体现出
: ingress qos的必要了
:
: 上

avatar
z*r
9
这个俺同意,但是分类(classification)严格上说并不是QoS啊,分类了以后接下来干的
事情才更重要






【在 u*v 的大作中提到】
: 俺对QoS研究很少,我想至少在MPLS TE有用,对进来的Traffic进行分类,确认打什么标
: 签,走哪条路经,以后就是标记交换了,所以必须在进MPLS时就打上tag。

avatar
L*t
10
QoS is implemented by priority queues. That's why the earlier we classify
traffic into different queues, the better.



【在 z**r 的大作中提到】
: 这个俺同意,但是分类(classification)严格上说并不是QoS啊,分类了以后接下来干的
: 事情才更重要
:
: 根
: 加
: 成
: 客

avatar
z*r
11
but the problem is, if the interface/lien card is not oversubscribed, the low
latency queue is actually not meanning too much, actually, in this situation,
as long as we have enough queue depth, we even don't need to worry about the
priorities

,

【在 L******t 的大作中提到】
: My guess is ingress traffic can be put into queues of different priorities.
: The queue of absolute priority is of course taken care of faster than others,
: thus low latency.
:
: 可
: 会

avatar
w*n
12
感觉你在某个router vendor有间谍啊



【在 z**r 的大作中提到】
: 这个egress qos比较好理解,这个ingress qos,尤其ingress queueing,应该如何理解
: ?

avatar
z*r
13


【在 w********n 的大作中提到】
: 感觉你在某个router vendor有间谍啊
:
: 解

avatar
u*v
14
正是这样的,这些都应该在PE上处理的。现在的问题是,traffic在Ingress的线卡上就根
据需要进行了IP分类,然后通过背板,在进入MPLS处理块对IP分类进行到EXP的映射及加
标记等处理,后面就是MPLS的机制了。当然理论上说,IP分类完全可以在CE或之前就完成
,但要记住,PE是运营商的设备,而CE完全可以不是运营商的设备,运营商不可能信任客
户的IP分类,它必须在PE入口根据SLA再做一次IP分类。另外我同意前面的一些说法,对非MPLS的情况,在Ingress这样处理有时也是很必要的,QOS很多时候在线卡上就完成了,实际上你应该把ROUTER,特别是大的象GSR,CRS-1,T640,看成线卡(里面包括线卡控制,分布式路由表等其它东西)、核心路由表维护、核心交换、核心控制等功能块独立组成,这样就不难理解了。

【在 z**r 的大作中提到】
: MPLW EXP bits都是在做mpls imposition的时候,要么从cos bits,要么从ip
: precedence要么从dscp copy 过去的,当然也可以人工set,但是都是发生在ingress
: traffic已经进到了router以后。当然俺说的这个市ip2mpls,在做swap的时候,也可以
: classify based on exp bits,但是对于ingress qos来说,只是classification的不同
: ,并没有对queueing产生
: 任何影响
:
: 标

avatar
z*r
15
if the interface is not oversubscribed, in most cases(if no line card
oversubscription), the queue depth would be always 0. we even don't need a
very big buffer.
the situation you mentioned is exactly what I am concerned. the low latency
queue on port B would not mean much.

interfaces
has

【在 L******t 的大作中提到】
: QoS is implemented by priority queues. That's why the earlier we classify
: traffic into different queues, the better.
:
: 的

avatar
L*t
16
My guess is ingress traffic can be put into queues of different priorities.
The queue of absolute priority is of course taken care of faster than others,
thus low latency.




【在 z**r 的大作中提到】
: if the interface is not oversubscribed, in most cases(if no line card
: oversubscription), the queue depth would be always 0. we even don't need a
: very big buffer.
: the situation you mentioned is exactly what I am concerned. the low latency
: queue on port B would not mean much.
:
: interfaces
: has

avatar
z*r
17
嗯,你这个说的是另外一个种可能,尤其是ingress line card oversubscription的情况

A

traffic



【在 L******t 的大作中提到】
: My guess is ingress traffic can be put into queues of different priorities.
: The queue of absolute priority is of course taken care of faster than others,
: thus low latency.
:
: 可
: 会

avatar
z*r
18

第一个不应该是,如果到了fabric都oversubscribed了的话,任何traffic都没有办法保
证了。除非是一个特殊的traffic pattern。
can you explain more?

【在 c*a 的大作中提到】
: just a guess,
: 1. backplane (fabric oversubscription?)
: 2. resource contention when 2+ inbound if competing same outbound if
: other than interface ingress/egress qos, some products do fabric qos
:
: 可
: 会

avatar
L*t
19
我上上篇帖子没说清楚。假设一个controller/arbiter控制两个PHY port A & B;port A
满载,但全是垃圾traffic,port B undersubscribed,但是VOIP traffic。这种情况下
,如果两个PHY port分别只有一个queue的话,arbiter作round robin,port B traffic
will suffer even though it's undersubscribed. Port A的垃圾traffic会一路上去让
别人suffer直到classification point.不用说更经常的情况是一个arbiter控制4个或者
更多PHY ports.
所以说如果单个port不oversubscribed,不影响multiple queueing的必要性.如果都不
oversubscribed的话,共产主义就来到了.



【在 z**r 的大作中提到】
: 俺好像突然明白了些,即使interface没有oversubscribe,那么相应的policy中的某一个
: class还是有可能oversubscribed的,恰好这个class是一个高级别的queue,就体现出
: ingress qos的必要了
:
: 上

avatar
z*r
20
根具体环境无关,就是想知道这个东西到底有什么用。ingress policing, ingress
shaping都好说,比较不好理解的是ingress low latency queue,对于egress queue,可
以轻易oversubscribe interface,这个egress llq就很straightforward,可对于
ingress llq,这个interface物理限制就是那么多,也就是进来的traffic,怎么都不会
oversubscribe这个interface,这个时候ingress llq能起什么作用呢?

【在 u*v 的大作中提到】
: 正是这样的,这些都应该在PE上处理的。现在的问题是,traffic在Ingress的线卡上就根
: 据需要进行了IP分类,然后通过背板,在进入MPLS处理块对IP分类进行到EXP的映射及加
: 标记等处理,后面就是MPLS的机制了。当然理论上说,IP分类完全可以在CE或之前就完成
: ,但要记住,PE是运营商的设备,而CE完全可以不是运营商的设备,运营商不可能信任客
: 户的IP分类,它必须在PE入口根据SLA再做一次IP分类。另外我同意前面的一些说法,对非MPLS的情况,在Ingress这样处理有时也是很必要的,QOS很多时候在线卡上就完成了,实际上你应该把ROUTER,特别是大的象GSR,CRS-1,T640,看成线卡(里面包括线卡控制,分布式路由表等其它东西)、核心路由表维护、核心交换、核心控制等功能块独立组成,这样就不难理解了。

相关阅读
logo
联系我们隐私协议©2024 redian.news
Redian新闻
Redian.news刊载任何文章,不代表同意其说法或描述,仅为提供更多信息,也不构成任何建议。文章信息的合法性及真实性由其作者负责,与Redian.news及其运营公司无关。欢迎投稿,如发现稿件侵权,或作者不愿在本网发表文章,请版权拥有者通知本网处理。