Hi Jason, Please don't drop the mailing list. Ryu-devel <[email protected]>
> Thank you for replying. Could you please provide any testing methods to > observe the relationship between packets with different priority values? > For example, packets with lower priority will be dropped and the result > can be observed by using the iperf command at the server node. > Or could you please provide us the method of verifying the functionality > of setting priority which your Ryu SDN research group adopted? > I would appreciate your help! First, Ryu-devel have announced release of QoS chapter in Ryu book English edition. I hope it will be helpful for you. -------- Forwarded Message -------- Subject: [Ryu-devel] QoS chapter in Ryu book English edition available! Date: Tue, 23 Dec 2014 14:15:18 +0900 (JST) From: FUJITA Tomonori <[email protected]> To: [email protected] QoS chapter had been avaiable in only Japanese edition. Now it was translated into English: http://osrg.github.io/ryu-book/en/html/rest_qos.html pdf, mobi, and epub formats are supposed to be updated too. Thanks so much to Yusuke and Minoru! ------------------------------------ In Ryu-book, iperf command is used for testing the bandwidth, and just as you say, packets with the lower priority will be dropped or delay in the QoS network. And, Vilius Palubinskas([email protected]) introduced you another tool for QoS analysis, IDG (http://traffic.comics.unina.it/software/ITG/). How about trying this tool? -------- Forwarded Message -------- Subject: Re: [Ryu-devel] QoS-Discussion(II) Date: Tue, 16 Dec 2014 08:52:58 +0200 From: Vilius Palubinskas <[email protected]> To: 'Jason Syu' <[email protected]> CC: [email protected] Hello, I want you introduce another tool for QoS analysis. Try IDG http://traffic.comics.unina.it/software/ITG/, it gives more flexibility for analysis of network QoS that iperf. Regards, Vilius. ------------------------------------ Thanks On 2014年12月23日 16:14, Jason Syu wrote: > Dear Mr. Yusuke, > Thank you for replying. Could you please provide any testing methods to > observe the relationship between packets with different priority values? For > example, packets with lower priority will be dropped and the result can be > observed by using the iperf command at the server node. Or could you please > provide us the method of verifying the functionality of setting priority > which your Ryu SDN research group adopted? I would appreciate your help! > > 2014-12-22 14:08 GMT+08:00 Yusuke Iwase <[email protected] > <mailto:[email protected]>>: > > Hi Jason, > > Please don't drop the mailing list. > Ryu-devel <[email protected] > <mailto:[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://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]> <mailto:[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://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]>> > <mailto:[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]> > <mailto:[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]> > <mailto:[email protected] <mailto:[email protected]>> > > > > > > > > > -- > Best wishes, > > Jason > > Department of Electronic and Computer Engineering, > National Taiwan University of Science and Technology (NTUST) > > ------------------------------------------------------------------------------ Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net _______________________________________________ Ryu-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ryu-devel
