Re: [ns] two equal UDP CBR flows in droptail queue get different bandwidths?
Hi, I think that the observed phenomenon depends on how the queue is serviced too. Part of the explanation is that the MAC layer is fetching those packets from the queue in a constant pace. And basically this means that your network isn't loaded enough so that it causes some randomness to be introduced when servicing the queue (ex: back-off timers). That phenomenon depends on which packet caused the queue to be full first, at which rate the packets are coming to the queue and the bandwidth of the MAC layer. Regards, Ilyes Gouta. On 6/8/06, Pedro Vale Estrela [EMAIL PROTECTED] wrote: This is an EXCELENT description of what happens in a non-randomized simulation, and from my experience, I fully agree on that. It is exactly this kind of material that would be very useful for the NS2 Wiki, to store this information permanently! As such, somebody on this list please contribute it to the NS2 wiki pages! Pedro Vale Estrela -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tyler Ross Sent: quinta-feira, 8 de Junho de 2006 16:43 To: Eduardo J. Ortega Cc: ns-users@ISI.EDU Subject: Re: [ns] two equal UDP CBR flows in droptail queue get different bandwidths? In reality, sure. What's happening with the simulation though, is that the packets are being sent at the same time. Even though you start the flows sending at t=0 and t=10, when they're both sending, they're sending at the exact same instant. Since internally, everything is handled in a fixed order and nothing is random unless you explicitly make it so, it will always drop the packets from the same source at the same time. Not because it picked the packets from that source to drop, but because that's just the order of things. And once you see how it works for one packet being dropped, the same thing will repeat itself over and over, since no variables are changing. I don't know if that makes sense. Think on the level of one packet (from each source). As you pointed out, the two flows have EXACTLY the same characteristics. So they leave the source at the same time, they take the same amount of time to travel down their respective links, and they arrive at the relay node at the EXACT same time. Problem is, only one packet can actually ride the next link. Yes, they will queue up until the queue is full. Then what? Which one is accepted into queue? Which is dropped? You know that DropTail has no fairness. So it's NOT going to pick the packet from the flow that was dropped last time. It's NOT going to pick one at random. So how will the simulator decide? If you have an array with all the packets and you loop over them, then the first one it comes across gets to join the queue. So which one gets to join the queue is determined by its internal order. Since nothing in the simulation is being changed in your simulation... you can do the same thing 1000 times, and the same thing will happen. So the next time a packet comes along, the same packet will be let through. The only way to change this result is to introduce some randomness to the sending order or to modify the how packets are queued. An even better idea is to prevent packets from being lost in the first place. :) Eduardo J. Ortega wrote: I understand that Droptail knows nothing about fairness. But, on the average, and given the fact that both flows have exactly the same characteristics, shouldn't they experience the same average behaviour? thanks. On Wednesday 07 June 2006 08:35, Tyler Ross wrote: This phenomenon is explained in the tutorial in Marc Greis's tutorial on the ns-2 website (see http://www.isi.edu/nsnam/ns/tutorial/nsscript2.html ). The queue that you're probably using is a DropTail. The DropTail queue has no concept of fairness, so it's going to drop whatever packet happens to be there. If you want some kind of fairness, you can do as the tutorial suggests, and replace DropTail with SFQ in your simulation. You will then get a fairer split of the bandwidth. If you monitor the queue and the dropped packets, you will indeed see that they are queued and dropped in a much more equal way. Eduardo J. Ortega wrote: Hi there: I've set up this experiment. I have two source nodes S1 and S2 directly connected to a node R1 and two destination nodes D1 and D2 also directly connected to a node R2. Nodes R1 and R2 are connected. All links are 1 Mb/s Full duplex with DropTail. Now, here's the thing. I set up two flows, one going from S1 to D1 and the other one form S2 to D2. Both flows are UDP CBR 1 Mb/s. Flow 1 starts at t=0 and finishes at t=20. flow 2 starts at t=10 and stops at t=15. Sim runs from t=0 to t=25. I'd expect that at t=10 (when flow 2 starts), both flows would experience the same amount of packet losses, so that each one
Re: [ns] two equal UDP CBR flows in droptail queue get different bandwidths?
In reality, sure. What's happening with the simulation though, is that the packets are being sent at the same time. Even though you start the flows sending at t=0 and t=10, when they're both sending, they're sending at the exact same instant. Since internally, everything is handled in a fixed order and nothing is random unless you explicitly make it so, it will always drop the packets from the same source at the same time. Not because it picked the packets from that source to drop, but because that's just the order of things. And once you see how it works for one packet being dropped, the same thing will repeat itself over and over, since no variables are changing. I don't know if that makes sense. Think on the level of one packet (from each source). As you pointed out, the two flows have EXACTLY the same characteristics. So they leave the source at the same time, they take the same amount of time to travel down their respective links, and they arrive at the relay node at the EXACT same time. Problem is, only one packet can actually ride the next link. Yes, they will queue up until the queue is full. Then what? Which one is accepted into queue? Which is dropped? You know that DropTail has no fairness. So it's NOT going to pick the packet from the flow that was dropped last time. It's NOT going to pick one at random. So how will the simulator decide? If you have an array with all the packets and you loop over them, then the first one it comes across gets to join the queue. So which one gets to join the queue is determined by its internal order. Since nothing in the simulation is being changed in your simulation... you can do the same thing 1000 times, and the same thing will happen. So the next time a packet comes along, the same packet will be let through. The only way to change this result is to introduce some randomness to the sending order or to modify the how packets are queued. An even better idea is to prevent packets from being lost in the first place. :) Eduardo J. Ortega wrote: I understand that Droptail knows nothing about fairness. But, on the average, and given the fact that both flows have exactly the same characteristics, shouldn't they experience the same average behaviour? thanks. On Wednesday 07 June 2006 08:35, Tyler Ross wrote: This phenomenon is explained in the tutorial in Marc Greis's tutorial on the ns-2 website (see http://www.isi.edu/nsnam/ns/tutorial/nsscript2.html ). The queue that you're probably using is a DropTail. The DropTail queue has no concept of fairness, so it's going to drop whatever packet happens to be there. If you want some kind of fairness, you can do as the tutorial suggests, and replace DropTail with SFQ in your simulation. You will then get a fairer split of the bandwidth. If you monitor the queue and the dropped packets, you will indeed see that they are queued and dropped in a much more equal way. Eduardo J. Ortega wrote: Hi there: I've set up this experiment. I have two source nodes S1 and S2 directly connected to a node R1 and two destination nodes D1 and D2 also directly connected to a node R2. Nodes R1 and R2 are connected. All links are 1 Mb/s Full duplex with DropTail. Now, here's the thing. I set up two flows, one going from S1 to D1 and the other one form S2 to D2. Both flows are UDP CBR 1 Mb/s. Flow 1 starts at t=0 and finishes at t=20. flow 2 starts at t=10 and stops at t=15. Sim runs from t=0 to t=25. I'd expect that at t=10 (when flow 2 starts), both flows would experience the same amount of packet losses, so that each one would use about 0.5Mb/s of the link between R1 and R2. But what really happens is that from t=10 to t=15, flow 2 uses all bandwidth while flow 1 loses all packets. Since both flows have the same parameters, shouldn't they receive the same share of bandwidth during that period? Or am i missing something here? Thanks in advance.
Re: [ns] two equal UDP CBR flows in droptail queue get different bandwidths?
This is an EXCELENT description of what happens in a non-randomized simulation, and from my experience, I fully agree on that. It is exactly this kind of material that would be very useful for the NS2 Wiki, to store this information permanently! As such, somebody on this list please contribute it to the NS2 wiki pages! Pedro Vale Estrela -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tyler Ross Sent: quinta-feira, 8 de Junho de 2006 16:43 To: Eduardo J. Ortega Cc: ns-users@ISI.EDU Subject: Re: [ns] two equal UDP CBR flows in droptail queue get different bandwidths? In reality, sure. What's happening with the simulation though, is that the packets are being sent at the same time. Even though you start the flows sending at t=0 and t=10, when they're both sending, they're sending at the exact same instant. Since internally, everything is handled in a fixed order and nothing is random unless you explicitly make it so, it will always drop the packets from the same source at the same time. Not because it picked the packets from that source to drop, but because that's just the order of things. And once you see how it works for one packet being dropped, the same thing will repeat itself over and over, since no variables are changing. I don't know if that makes sense. Think on the level of one packet (from each source). As you pointed out, the two flows have EXACTLY the same characteristics. So they leave the source at the same time, they take the same amount of time to travel down their respective links, and they arrive at the relay node at the EXACT same time. Problem is, only one packet can actually ride the next link. Yes, they will queue up until the queue is full. Then what? Which one is accepted into queue? Which is dropped? You know that DropTail has no fairness. So it's NOT going to pick the packet from the flow that was dropped last time. It's NOT going to pick one at random. So how will the simulator decide? If you have an array with all the packets and you loop over them, then the first one it comes across gets to join the queue. So which one gets to join the queue is determined by its internal order. Since nothing in the simulation is being changed in your simulation... you can do the same thing 1000 times, and the same thing will happen. So the next time a packet comes along, the same packet will be let through. The only way to change this result is to introduce some randomness to the sending order or to modify the how packets are queued. An even better idea is to prevent packets from being lost in the first place. :) Eduardo J. Ortega wrote: I understand that Droptail knows nothing about fairness. But, on the average, and given the fact that both flows have exactly the same characteristics, shouldn't they experience the same average behaviour? thanks. On Wednesday 07 June 2006 08:35, Tyler Ross wrote: This phenomenon is explained in the tutorial in Marc Greis's tutorial on the ns-2 website (see http://www.isi.edu/nsnam/ns/tutorial/nsscript2.html ). The queue that you're probably using is a DropTail. The DropTail queue has no concept of fairness, so it's going to drop whatever packet happens to be there. If you want some kind of fairness, you can do as the tutorial suggests, and replace DropTail with SFQ in your simulation. You will then get a fairer split of the bandwidth. If you monitor the queue and the dropped packets, you will indeed see that they are queued and dropped in a much more equal way. Eduardo J. Ortega wrote: Hi there: I've set up this experiment. I have two source nodes S1 and S2 directly connected to a node R1 and two destination nodes D1 and D2 also directly connected to a node R2. Nodes R1 and R2 are connected. All links are 1 Mb/s Full duplex with DropTail. Now, here's the thing. I set up two flows, one going from S1 to D1 and the other one form S2 to D2. Both flows are UDP CBR 1 Mb/s. Flow 1 starts at t=0 and finishes at t=20. flow 2 starts at t=10 and stops at t=15. Sim runs from t=0 to t=25. I'd expect that at t=10 (when flow 2 starts), both flows would experience the same amount of packet losses, so that each one would use about 0.5Mb/s of the link between R1 and R2. But what really happens is that from t=10 to t=15, flow 2 uses all bandwidth while flow 1 loses all packets. Since both flows have the same parameters, shouldn't they receive the same share of bandwidth during that period? Or am i missing something here? Thanks in advance.
Re: [ns] two equal UDP CBR flows in droptail queue get different bandwidths?
This phenomenon is explained in the tutorial in Marc Greis's tutorial on the ns-2 website (see http://www.isi.edu/nsnam/ns/tutorial/nsscript2.html ). The queue that you're probably using is a DropTail. The DropTail queue has no concept of fairness, so it's going to drop whatever packet happens to be there. If you want some kind of fairness, you can do as the tutorial suggests, and replace DropTail with SFQ in your simulation. You will then get a fairer split of the bandwidth. If you monitor the queue and the dropped packets, you will indeed see that they are queued and dropped in a much more equal way. Eduardo J. Ortega wrote: Hi there: I've set up this experiment. I have two source nodes S1 and S2 directly connected to a node R1 and two destination nodes D1 and D2 also directly connected to a node R2. Nodes R1 and R2 are connected. All links are 1 Mb/s Full duplex with DropTail. Now, here's the thing. I set up two flows, one going from S1 to D1 and the other one form S2 to D2. Both flows are UDP CBR 1 Mb/s. Flow 1 starts at t=0 and finishes at t=20. flow 2 starts at t=10 and stops at t=15. Sim runs from t=0 to t=25. I'd expect that at t=10 (when flow 2 starts), both flows would experience the same amount of packet losses, so that each one would use about 0.5Mb/s of the link between R1 and R2. But what really happens is that from t=10 to t=15, flow 2 uses all bandwidth while flow 1 loses all packets. Since both flows have the same parameters, shouldn't they receive the same share of bandwidth during that period? Or am i missing something here? Thanks in advance.
Re: [ns] two equal UDP CBR flows in droptail queue get different bandwidths?
I understand that Droptail knows nothing about fairness. But, on the average, and given the fact that both flows have exactly the same characteristics, shouldn't they experience the same average behaviour? thanks. On Wednesday 07 June 2006 08:35, Tyler Ross wrote: This phenomenon is explained in the tutorial in Marc Greis's tutorial on the ns-2 website (see http://www.isi.edu/nsnam/ns/tutorial/nsscript2.html ). The queue that you're probably using is a DropTail. The DropTail queue has no concept of fairness, so it's going to drop whatever packet happens to be there. If you want some kind of fairness, you can do as the tutorial suggests, and replace DropTail with SFQ in your simulation. You will then get a fairer split of the bandwidth. If you monitor the queue and the dropped packets, you will indeed see that they are queued and dropped in a much more equal way. Eduardo J. Ortega wrote: Hi there: I've set up this experiment. I have two source nodes S1 and S2 directly connected to a node R1 and two destination nodes D1 and D2 also directly connected to a node R2. Nodes R1 and R2 are connected. All links are 1 Mb/s Full duplex with DropTail. Now, here's the thing. I set up two flows, one going from S1 to D1 and the other one form S2 to D2. Both flows are UDP CBR 1 Mb/s. Flow 1 starts at t=0 and finishes at t=20. flow 2 starts at t=10 and stops at t=15. Sim runs from t=0 to t=25. I'd expect that at t=10 (when flow 2 starts), both flows would experience the same amount of packet losses, so that each one would use about 0.5Mb/s of the link between R1 and R2. But what really happens is that from t=10 to t=15, flow 2 uses all bandwidth while flow 1 loses all packets. Since both flows have the same parameters, shouldn't they receive the same share of bandwidth during that period? Or am i missing something here? Thanks in advance. -- Eduardo J. Ortega - Linux user #222873 No fake - I'm a big fan of konqueror, and I use it for everything. -- Linus Torvalds
