Hi Jason,

Please don't drop the mailing list.
 Ryu-devel <[email protected]>


> In your previous reply, you advised me to set the priority of the queue.
> However, at the end of QoS chapter(REST API List), the parameters that
> can be modified includes (1)port_name,(2)type,(3)max_rate,(4)queues_max_rate
> and (5)queues_min_rate.
> There is no priority setting for the Queue itself.
> I can only set the priority in the above command(3).

Yes, there is no "priority" parameter for the Queue setting command obviously,
because there is no relationship between the Queue and "priority" parameter of 
command(3).

The setting which shows "a Queue has high bandwidth" means that
the flow entry assigned with the high bandwidth Queue can preferentially 
process the packets,
so I said the the high bandwidth Queue has the high priority.
("preferentially" means guarantee of minimum bandwidth and so on.)

In other words, "priority" of command(3) is used for controlling flow entry
matching mechanism, and I think you need not set the priority for the Queue 
itself...


Thanks

On 2014年12月18日 12:37, Jason Syu wrote:
> Dear Mr. Yusuke,
> 
>     I have modified the priority of client1(port 5001) and the steps are as 
> follows:
> (1) curl -X PUT -d '"tcp:127.0.0.1:6632 <http://127.0.0.1:6632>"' 
> http://localhost:8080/v1.0/conf/switches/0000000000000001/ovsdb_addr
> 
> (2) curl -X POST -d '{"port_name": "s1-eth1", "type": "linux-htb", 
> "max_rate": "1000000", "queues": [{"max_rate": "500000"},    {"min_rate": 
> "800000"}]}' http://localhost:8080/qos/queue/0000000000000001
> 
> (3) curl -X POST -d '{"priority":"3","match": {"nw_dst": "10.0.0.1", 
> "nw_proto": "UDP", "tp_dst": "5001"}, "actions":{"queue": "1"}}' 
> http://localhost:8080/qos/rules/0000000000000001
> 
> (4) (client 1) iperf -c 10.0.0.1 -p 5001 -n 5M -u -b 1M
>       (server)  iperf -s -u -i -p 5001
> 
> (5) (client 2) iperf -c 10.0.0.1 -p 5002 -n 5M -u -b 1M
>       (server)  iperf -s -u -i -p 5002
> 
> (6) (client 3) iperf -c 10.0.0.1 -p 5003 -n 5M -u -b 1M
>       (server)  iperf -s -u -i -p 5003 
> 
> Although I have modified the priority of port 5001, the minimum bandwidth 
> rule was broken once the other clients sent out their request.
> This situation is the same as the test case attached in the first mail. The 
> minimum bandwidth still can't be guaranteed. 
> ---------------------------------------------------------------------------------------------------
>> 1. Prepare the queue
>>   =======  ========================  ===========
>>   Queue 0  the low priority queue    Max 500Kbps <-- Not guaranteed
>>   Queue 1  the high priority queue   Min 800Kbps <-- Guarantee minimum 
>> bandwidth(800kbps)
>>   =======  ========================  ===========
> In your previous reply, you advised me to set the priority of the queue. 
> However, at the end of QoS chapter(REST API List), the parameters that can be 
> modified includes (1)port_name,(2)type,(3)max_rate,(4)queues_max_rate and 
> (5)queues_min_rate. There is no priority setting for the Queue itself. I can 
> only set the priority in the above command(3).
> 
> If I am wrong with the steps or priority setting, could you please identify 
> it for me? I would appreciate your kind help!
> 
> 
> 
> 
> 2014-12-16 15:06 GMT+08:00 Yusuke Iwase <[email protected] 
> <mailto:[email protected]>>:
> 
>     Hi Jason,
> 
>     I think you maybe have misunderstood.
> 
> 
>     > First, I used the command "iperf" to observe the server's reports
>     > which included the following parameters: interval, transfer, bandwidth,
>     > jitter, lost/total and datagrams.
>     > I also observed these parameters when I set the two clients' priority 
> to 1.
>     > However, I could not see any obvious differences between these two sets 
> of
>     > parameters.
>     > Do you use the same command to observe the server reports and use these
>     > parameters to check whether the priority setting worked?
>     > What parameters should I observe in this case?
> 
>     The "priority" parameter of the curl commands does NOT mean the priority 
> of
>     the communication, but it is the priority of OpenFlow matching mechanisms.
> 
>     If you want to assign the high priority to the specified communication,
>     you should install the flow entry that is related to the high bandwidth 
> queue
>     and it matches the specified communication.
> 
>     In other words, the priority of the communication does not depend on the 
> priority
>     of the curl commands.
>     Rather, it depends on the bandwidth of the assigned queue.
> 
> 
>     > Second, I also attached another testing case to this mail.
>     > I have described the second question in the file.
>     > Please see the attachment. Could you please offer me some useful 
> suggestions?
>     > I would appreciate your kind help.
> 
>     As described in the answer for the first question,
>     the priority of the communication depends on the bandwidth of the 
> assigned queue.
>     In your test case, the bandwidth of the assigned queue is all the same.
>     So, iperf command shows the same bandwidth.
> 
>     If you woant to guarantee one of the client's minimum bandwidth(800kbps),
>     you can do it with ryu like as follows.
> 
>     I used this environment.
>     (http://osrg.github.io/ryu-book/ja/html/rest_qos.html#id3)
> 
> 
>     1. Prepare the queue
>       =======  ========================  ===========
>       Queue 0  the low priority queue    Max 500Kbps <-- Not guaranteed
>       Queue 1  the high priority queue   Min 800Kbps <-- Guarantee minimum 
> bandwidth(800kbps)
>       =======  ========================  ===========
> 
>     $ curl -X PUT -d '"tcp:127.0.0.1:6632 <http://127.0.0.1:6632>"' 
> http://localhost:8080/v1.0/conf/switches/0000000000000001/ovsdb_addr
> 
>     $ curl -X POST -d '{"port_name": "s1-eth1", "type": "linux-htb", 
> "max_rate": "1000000", "queues": [{"max_rate": "500000"}, {"min_rate": 
> "800000"}]}' http://localhost:8080/qos/queue/0000000000000001
> 
> 
>     2. Install the flow entry for the high priority communication.
>       (If the high priority client use 5001 port.)
>        The following flow entry assignes the communication(use 5001 port) to 
> the high priority queue(Queue 1).
> 
>     $ curl -X POST -d '{"match": {"nw_dst": "10.0.0.1", "nw_proto": "UDP", 
> "tp_dst": "5001"}, "actions":{"queue": "1"}}' 
> http://localhost:8080/qos/rules/0000000000000001
> 
> 
>     3. Try to test iperf.
>     [Server]
>     > iperf -s -u -p 5001 &
>     > iperf -s -u -p 5002 &
>     > iperf -s -u -p 5003 &
> 
>     [Client]
>     > iperf -c 10.0.0.1 -p 5001 -u -b 1M
>       --> This shows to guarantee minimum bandwidth(800kbps)
> 
>     > iperf -c 10.0.0.1 -p 5002 -u -b 1M
>     > iperf -c 10.0.0.1 -p 5003 -u -b 1M
>       --> These are not guaranteed
> 
> 
>     Thanks
> 
>     On 2014年12月16日 14:27, Jason Syu wrote:
>     > Dear Mr. Takahashi
>     >     My name is Jason. I have tried the QoS example which you provided 
> last week. I still have two more questions. Could you provide me some 
> suggestions? Thank you!
>     >     First, I used the command "iperf" to observe the server's reports 
> which included the following parameters: interval, transfer, bandwidth, 
> jitter, lost/total and datagrams. I  also observed these parameters when I 
> set the two clients' priority to 1. However, I could not see any obvious 
> differences between these two sets of parameters. Do you use the same command 
> to observe the server reports and use these parameters to check whether the 
> priority setting worked?What parameters should I observe in this case?
>     >     Second, I also attached another testing case to this mail. I have 
> described the second question in the file. Please see the attachment. Could 
> you please offer me some useful suggestions? I would appreciate your kind 
> help.
>     > --
>     > Best wishes,
>     >
>     > Jason Syu
>     >
>     > Department of Electronic and Computer Engineering,
>     > National Taiwan University of Science and Technology (NTUST)
>     > Email: [email protected] <mailto:[email protected]> 
> <mailto:[email protected] <mailto:[email protected]>>
>     >
>     >
>     >
>     >
>     > 
> ------------------------------------------------------------------------------
>     > Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
>     > from Actuate! Instantly Supercharge Your Business Reports and Dashboards
>     > with Interactivity, Sharing, Native Excel Exports, App Integration & 
> more
>     > Get technology previously reserved for billion-dollar corporations, FREE
>     > 
> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
>     >
>     >
>     >
>     > _______________________________________________
>     > Ryu-devel mailing list
>     > [email protected] <mailto:[email protected]>
>     > https://lists.sourceforge.net/lists/listinfo/ryu-devel
>     >
> 
> 
> 
> -- 
> Best wishes,
> 
> Jason
> 
> Department of Electronic and Computer Engineering,
> National Taiwan University of Science and Technology (NTUST)
> Email: [email protected] <mailto:[email protected]>
> 
> 

------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
Ryu-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ryu-devel

Reply via email to