Dear Mr. Yusuke Iwase
Thank you very much for replying and the explanation!
2014-12-25 13:28 GMT+08:00 Yusuke Iwase <[email protected]>:
> Dear Mr.Jason,
>
> Please don't drop the mailing list.
> Ryu-devel <[email protected]>
>
> > I am wondering if the action "drop" exists in your code.
> > However, it seems the packets can only go from table 0 to table 1.
> > I have traced the rest_qos.py and it indicates that packets can
> > only go from table 0 to table 1.
>
> Example of QoS chapter "Example of the operation of the per-flow QoS"
> does not use "drop" action.
> This example uses only "set_queue" action.
> Therefore, packet scheduling (which packet to drop or when to forward
> packet)
> using queues depends on the switch implemtation.
> (
> http://osrg.github.io/ryu-book/en/html/rest_qos.html#example-of-the-operation-of-the-per-flow-qos
> )
>
>
> > Can your code(rest_qos.py) be extended to provide more flow tables?
>
> In API reference, "Set a QoS rule" command provides 3 methods.
> (http://osrg.github.io/ryu-book/en/html/rest_qos.html#set-a-qos-rule)
> "mark" provides "DSCP_REMARK" actions,
> "meter" provides "METER" actions,
> "queue" provides "SET_QUEUE" actions. <-- which I used.
>
>
> > Besides, in the first example of QoS chapter, I extended the number of
> clients to 5 and the command was as follows:
> >>>curl -X POST -d '{"port_name": "s1-eth1", "type": "linux-htb",
> "max_rate": "2200000", "queues": [{"max_rate": "500000"}, {"min_rate":
> "400000"}, , {"min_rate": "500000"}, {"min_rate": "600000"}, {"min_rate":
> "1500000"}]}' http://localhost:8080/qos/queue/0000000000000001
> >
> > The queue and port setting were as follows:
> > CL1 : Port 5001 : Queue 0 : max_rate: 500k bps
> > CL2 : Port 5002 : Queue 1 : min_rate: 400k bps
> > CL3 : Port 5003 : Queue 2 : min_rate: 500k bps
> > CL4 : Port 5004 : Queue 3 : min_rate: 600k bps
> > CL5 : Port 5005 : Queue 4 : min_rate: 1.5M bps
> >
> > CL2,CL3,CL4,CL5 made requests of 5M data to the same server(10.0.0.1)
> and the clients' bandwidth values were as follows:
> > CL2 : around 380k bps ~ 390k bps
> > CL3 : around 490k bps
> > CL4 : around 580k bps ~ 590k bps
> > CL5 : around 1.46M bps
> > In this case, the clients' total bandwidth(390k + 490k + 590k +1.46M ≒
> 2.96M bps) exceeded the max_rate 2200000 bps. It's quite confusing that the
> clients' bandwidth exceeds the max bandwidth. If there exists any problems
> in my testing process, could you please kindly identify them? I would
> appreciate your help.
>
> The total min_rate(400K + 500K + 600K + 1.5M = 3.0M) exceeded the max_rate
> 2.2M, didn't it?
> I guess it depends on the switch implemtation...
>
>
> Thanks
>
> On 2014年12月25日 02:16, Jason Syu wrote:
> > Dear Mr. Yusuke,
> > Thank you very much for your help and the English version of QoS
> chapter. I have tried the tool D-ITG introduced by Mr. Vilius Palubinskas.
> However, I haven't figure out the D-ITG parameters for verifying the
> priority function. Actually, I found a video on Youtube which demonstrates
> the flow table priority function. Please refer to the link below.
> >
> > (starting from 5:00)
> > https://www.youtube.com/watch?v=FyV4MoQ3T0I
> >
> > I am wondering if the action "drop" exists in your code. However, it
> seems the packets can only go from table 0 to table 1. I have traced the
> rest_qos.py and it indicates that packets can only go from table 0 to table
> 1. Can your code(rest_qos.py) be extended to provide more flow tables?
> >
> > Besides, in the first example of QoS chapter, I extended the number of
> clients to 5 and the command was as follows:
> >>>curl -X POST -d '{"port_name": "s1-eth1", "type": "linux-htb",
> "max_rate": "2200000", "queues": [{"max_rate": "500000"}, {"min_rate":
> "400000"}, , {"min_rate": "500000"}, {"min_rate": "600000"}, {"min_rate":
> "1500000"}]}' http://localhost:8080/qos/queue/0000000000000001
> >
> > The queue and port setting were as follows:
> > CL1 : Port 5001 : Queue 0 : max_rate: 500k bps
> > CL2 : Port 5002 : Queue 1 : min_rate: 400k bps
> > CL3 : Port 5003 : Queue 2 : min_rate: 500k bps
> > CL4 : Port 5004 : Queue 3 : min_rate: 600k bps
> > CL5 : Port 5005 : Queue 4 : min_rate: 1.5M bps
> >
> > CL2,CL3,CL4,CL5 made requests of 5M data to the same server(10.0.0.1)
> and the clients' bandwidth values were as follows:
> > CL2 : around 380k bps ~ 390k bps
> > CL3 : around 490k bps
> > CL4 : around 580k bps ~ 590k bps
> > CL5 : around 1.46M bps
> > In this case, the clients' total bandwidth(390k + 490k + 590k +1.46M ≒
> 2.96M bps) exceeded the max_rate 2200000 bps. It's quite confusing that the
> clients' bandwidth exceeds the max bandwidth. If there exists any problems
> in my testing process, could you please kindly identify them? I would
> appreciate your help.
> >
> >
> >
> >
> >
> > 2014-12-24 10:09 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]>>
> >
> >
> > > 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] <mailto:
> [email protected]>>
> > To: [email protected] <mailto:
> [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] <mailto:
> [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] <mailto:
> [email protected]>>
> > To: 'Jason Syu' <[email protected] <mailto:[email protected]
> >>
> > CC: [email protected] <mailto:
> [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]> <mailto:[email protected] <mailto:
> [email protected]>>>:
> > >
> > > Hi Jason,
> > >
> > > Please don't drop the mailing list.
> > > Ryu-devel <[email protected] <mailto:
> [email protected]> <mailto:[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://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]>> <mailto:
> [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://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]>>> <mailto:[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]>> <mailto:
> [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]>> <mailto:
> [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)
> > >
> > >
> >
> >
> >
> >
> > --
> > Best wishes,
> >
> > Jason
> >
> > Department of Electronic and Computer Engineering,
> > National Taiwan University of Science and Technology (NTUST)
> >
> >
>
--
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
