Re: Problems about Introduce Flow-aware Bandwidth constraint,Thanks
Luca Prete
Today, we reserve bandwidth in the intent framework -through the ConnectivityIntentCompiler.
This is straightforward for p2p intents (i.e. if you want to allocate bw N between two points, it's clear that N should be the bandwdith to be allocated on each port between the two points).
It is not that straight forward instead for sp2mp and mp2sp. Let's take the example of a multi-point to single-point intent. Let's say you have two ingress points and one egress point. What does it mean give to this intent 10Mbps? Right now, we just reserve 10Mbps everywhere along the path, even if we're after the branching point where the two branches merge. ...Probably the right thing to do would be assigning instead 10Mbps everywhere on the single ingress branches, to then allocate 20Mbps from where the two branches merge till destination...
I think you're also confusing allocation (aka reservation) with enforcement. Reservation means that on the control plane (only in ONOS, not on the devices!) we know a-priori how much bandwdith a certain port can support. Every time we need some bandwidth, we check if there's enough bandwidth that can be allocated on that port. If there's no enough bandwidth, ONOS doesn't install the flow; otherwise, it allocates the bandwidth (simply, a subtraction in the reservation subsystem: new bw available = old bw available - bw required) and it installs the intent.
In my mind, we should check before if there's enough bandwidth along the path (what we already do). If there's enough bandwidth we allocate it. Then, if the device at the ingress supports bw enforcement (i.e. through OF meters) we enforce it.
-Luca
Hi,y-higuchi
I am now reaching on onos story of ONOS-5848 Introduce Flow-aware Bandwidth constraint,I have some problems about it,In the description of the information,you say "For intents other than point-to-point, amount of bandwidth to allocate is not straight forward.",
How to understand of this? Do you mean allocation strategy today with ONOS-5808 is using the max of all incoming flows,but not using the sum of each incoming flows?
And do you mean the egress port bandwidth is not allocated, so there should be a constraint so that strategy which takes a sum of ingress BW will be allocated for the egress?
As far as I known, In ODL,bandwidth allocates are only considered at the ingress port, mainly to prevent stream from exceeding the limit into the device, it does not consider the bandwidth allocation of the egress,how much traffic comes in let it go out,
Is ONOS need to consider the port bandwidth settings?
Do you have ONOS business to establish the relevant documents? Or do you have a document that has a bandwidth adjustment related to the testing process? Thank you very much!
Zhiyong
kezhiyong
IT Development Engineer
Standard Preresearch Dept./Wireline Product R＆D Institute/Wireline Product Operation
ZTE Building, #6, HuaShiYuan Rd, East Lake New Technology,
Development Zone, Wuhan, Hubei, P.R.China, 430223T: +86 027 51811000 8110
www.zte.com.cn
ke.zh...@zte.com.cn
Hi,Luca
I studied the ConnectivityIntentCompiler to the bandwidth allocation part of the code, there are several questions:
I looking at the code from the testTwoIngressCompilation method of the MultiPointToSinglePointIntentCompilerTest class until the allocateBandwidth method of the ConnectivityIntentCompiler found some problems:
1. From the multi-point to single-point intent of the test code testTwoIngressCompilation, why not see the setting of bandwith? But in the method of allocateBandwidth can directly take "double bw = bwConstraint.bandwidth (). Bps ()";
Although there has the bandwidth settings in the class of BandwidthConstraint,but it's used in the other test cases,How this test case is passed?
2. In the method of allocateBandwidth of the class ConnectivityIntentCompiler, each intent can only get a bandwidth value "double bw = bwConstraint.bandwidth (). Bps ()"; if both 2G and 3G traffic comes in,
Do we give each ingress the same bandwidth constraint value? If the constraint bandwith value is set relatively large,i.e. if set 10G, is there must set 10G * N (N for the number of path) in egress constraint of bandwith,so is it save? but this egress constraint is easy to exceed the capacity limit of the device,and the result is that we can not continue to allocate more traffics, how do you think so?
I think:
The current bandwidth constraints is bound with intent, that is, each intent only one bandwidth constraint value, This design seems to be unreasonable in front of the problem.
Can we bind the constraint of bandwidth to the path? but not to the intent? each path set one bandwidth constraint value, to each path of the ingress are assigned a constraint value, such as 2G traffic allocation 2G bandwidth, 3G traffic allocation of 3G bandwidth, and egress constraint bandwidth value is the sum of the ingress value, such as 5G, so Bandwidth utilization is very high.
We can set a MAP,use the path as the ID and the BandwidthConstraint for the value,for example Map ＜Path, BandwidthConstraint＞ bandwithConstraints = new HashMap ＜＞ (), and then modify the allocateBandwidth part of the code, Path Take their own bandwidth restrictions, such as 2G traffic to take 2G, 3G traffic to take 3G, and then set up egress, each node egress constraint bandwith only need to take the sum of BW from the MAP of the corresponding Path's bandwith ,but this change will involve changes in many places , how do you think so?
Zhiyong
柯志勇 kezhiyong
IT开发工程师 IT Development
Engineer
预研标准部/有线研究院/有线产品经营部 Standard Preresearch Dept./Wireline Product R＆D Institute/Wireline Product Operation
 |  湖北省武汉市东湖新技术开发区华师园路6号中兴通讯武汉研究所 |
| ZTE Building, #6, HuaShiYuan Rd, East Lake New Technology, Development Zone, Wuhan, Hubei, P.R.China, 430223 |
ke.zh...@zte.com.cn
Luca Prete
Hi,Luca
I studied the ConnectivityIntentCompiler to the bandwidth allocation part of the code, there are several questions:
I looking at the code from the testTwoIngressCompilation method of the MultiPointToSinglePointIntentCompilerTest class until the allocateBandwidth method of the ConnectivityIntentCompiler found some problems:
1. From the multi-point to single-point intent of the test code testTwoIngressCompilation, why not see the setting of bandwith? But in the method of allocateBandwidth can directly take "double bw = bwConstraint.bandwidth (). Bps ()";
Although there has the bandwidth settings in the class of BandwidthConstraint,but it's used in the other test cases,How this test case is passed?
2. In the method of allocateBandwidth of the class ConnectivityIntentCompiler, each intent can only get a bandwidth value "double bw = bwConstraint.bandwidth (). Bps ()"; if both 2G and 3G traffic comes in,
Do we give each ingress the same bandwidth constraint value? If the constraint bandwith value is set relatively large,i.e. if set 10G, is there must set 10G * N (N for the number of path) in egress constraint of bandwith,so is it save? but this egress constraint is easy to exceed the capacity limit of the device,and the result is that we can not continue to allocate more traffics, how do you think so?
I think:
The current bandwidth constraints is bound with intent, that is, each intent only one bandwidth constraint value, This design seems to be unreasonable in front of the problem.
Can we bind the constraint of bandwidth to the path? but not to the intent? each path set one bandwidth constraint value, to each path of the ingress are assigned a constraint value, such as 2G traffic allocation 2G bandwidth, 3G traffic allocation of 3G bandwidth, and egress constraint bandwidth value is the sum of the ingress value, such as 5G, so Bandwidth utilization is very high.
We can set a MAP,use the path as the ID and the BandwidthConstraint for the value,for example Map ＜Path, BandwidthConstraint＞ bandwithConstraints = new HashMap ＜＞ (), and then modify the allocateBandwidth part of the code, Path Take their own bandwidth restrictions, such as 2G traffic to take 2G, 3G traffic to take 3G, and then set up egress, each node egress constraint bandwith only need to take the sum of BW from the MAP of the corresponding Path's bandwith ,but this change will involve changes in many places , how do you think so?
* https://jira.onosproject.org/browse/ONOS-6176 (trivial, but needed - just to remove a cast from string to long in the cli command class)
Zhiyong
柯志勇 kezhiyong
IT开发工程师 IT Development Engineer
预研标准部/有线研究院/有线产品经营部 Standard Preresearch Dept./Wireline Product R＆D Institute/Wireline Product Operation
湖北省武汉市东湖新技术开发区华师园路6号中兴通讯武汉研究所
ZTE Building, #6, HuaShiYuan Rd, East Lake New Technology,
Development Zone, Wuhan, Hubei, P.R.China, 430223T: +86 027 51811000 8110
www.zte.com.cn
原始邮件发件人： ＜lu...@onlab.us＞;收件人：柯志勇10068695;
wu.sh...@zte.com.cn
Hi, Luca, Yuta
I tested the ONOS-5848 story. I think that for the mp2sp intent, it does not need to increase the bandwidth constraints from the branch to the end port. If a user wants the bandwidth constraints to be increased from the branch to the end port, maybe he can set a sp2sp intent for each flow, and set a separate bandwidth constraint for each sp2sp intent, instead of using mp2sp intent. In this way, the bandwidth constraints from the branch to the end port will be the sum of each intent.
This is also for sp2mp intent.
Specifially, if the sp2mp intent is for multicast service(e.g. IPTV), the traffic in the branch device will be copied and then tranfered to the end, so the traffic speed should be the same between source-to-branch and branch-to-end, nor you need to change the bandwidth constraint of the branch device.
So the ONOS-5848 story may not need to do?
Regards
Wu Shaoyong