Hi Ariel, some comments inlined below. Regards, Cristian
-----Original Message-----
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Ariel Rodriguez
Sent: Thursday, November 28, 2013 8:53 PM
To: dev at dpdk.org
Subject: [dpdk-dev] 4 Traffic classes per Pipe limitation
Hi, im working with the qos scheduler framework and i have a few
questions. Why the 4 traffic classes per pipe limitation? .
[Cristian] The DPDK hierarchical scheduler allows for 4 traffic classes with 4
packet queues per traffic class for each pipe (user). Traffic classes and
scheduled in strict priority, while queues within a pipe traffic class are
scheduled using byte-level Weighted Round Robin (WRR) with configured weights.
Since we have 16 packet queues per pipe (user), we could argue that actually 16
(sub)traffic classes are supported. When the weight ratio between different
queues of the same traffic class is high (e.g. 4:1, 8:1, 16:1, etc), then WRR
starts behaving like strict priority. If your mapping to traffic classes is
done using DSCP, you can simply map some DSCP values to different queues within
same traffic class as well.
Im developing a deep packet inspection solution for a telecom company and i
we need more than just 4 traffic classes per pipe. Im able to recognise
almost all layer 7 applications, such as youtube, p2p , netflix ,
google-ads , etc, etc and i really need to map this type of flows in
differents traffic classes.
[Cristian] Not sure I completely agree with you here.
The traffic classes are there for the reason of providing different levels of
delay (latency), delay variation (jitter), packet loss rate, etc. So, for
example, one possible mapping of traffic types to the 4 traffic classes might
be: voice = TC0 (highest priority), interactive video = TC1,
non-interactive/cached video = TC2, best effort traffic (file downloads, web
browsing, email, etc) = TC3 (lowest priority). In my opinion, youtube and
netflix could be considered as being part of the same traffic class (e.g. TC2),
as they have very similar (if not identical) requirements, probably same for
p2p and google-ads, email, web browsing, etc (where best effort traffic class
is probably applicable). If really needed, youtube and netflix could be mapped
to different queues of TC2.
If different service / actions need to be applied to different applications
that have the same scheduling requirements (and part of the same traffic
class), then this would probably have to be decided earlier during the
classification phase and e.g. rate limit youtube traffic per user using traffic
metering algorithms, block p2p traffic if you are a firewall, etc; these are
probably actions that could be enforced outside of scheduling/traffic
management.
The idea is mark each flow depending on the provisioning
information and assign that flows to different subport depending on the
information given and assign a pipe with the subscriber contract rate, but
we really need to have more than 4 traffic clases, because we want to
control the bandwidth of different layer 7 protocols flows. At most we
need 32 or 64 traffic classes per subscriber.
[Cristian] Bandwidth control could be done on both ingress side as well as
egress side.
On ingress, the amount of incoming traffic for a specific user
(flow/connection/application) could be limited to predefined values, with
potentially different levels for different classes of users (e.g. regular /
premium / company / etc).
On egress, several pipe profiles can be defined using the DPDK hierarchical
scheduler, which would allow setting up a different rate limit for each traffic
class for each user. Likewise, traffic classes can be rate limited at the
subport level (group of users).
I understand that in a given interval of time a subscriber dont
use more than 4 protocols simultaneously , generally speaking , or 4
traffic classes in dpdk qos terminology, but the framework doesnt allow us
to configure more traffic classes.
Im looking the code of qos scheduler and im not seeing why this
restriction. Is a performance problem, or a waste of resource problem? ,
maybe when the port grinder search for the active queues for each traffic
class the delay of iterating over all pipes and each traffic class is too
high.
Cisco have a bandwidth managment solution that claims to control a
million of subscribers simoultaneosly with 64 traffic classes per
subscriber (pipes) and 4 queues per traffic classes (Cisco solution calls
traffic clases as "Bandwith controller per service or BWC , a subscriber
can have 64 BWC simoultaneasly). Its this posible? maybe this guys
implements the bandwidth managment in hardware?.
Anyway i really need this feature , but if the qos scheduller
cannot scale to more than 4 traffic classes per pipe i would have to
implement a custom packet scheduler from scratch and i really dont want to
do that.
Thanks for the patience, and sorry for my rusty english, im from
Argentina.
Best Regards.
Ariel Horacio Rodriguez, Callis Technologies.
--------------------------------------------------------------
Intel Shannon Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263
Business address: Dromore House, East Park, Shannon, Co. Clare
This e-mail and any attachments may contain confidential material for the sole
use of the intended recipient(s). Any review or distribution by others is
strictly prohibited. If you are not the intended recipient, please contact the
sender and delete all copies.
