Hi Phil, But even if we apply rate controllers at the sources (say for each of the clients) the inherent unfairness in the queuing dynamics would over ride the effects of the rate controllers to provide fairness.
The point I am trying to make is to make transport layers work with the forwarding engine that can ensure fairness there should be a fair treatment of all packets in the queue. One way I would think this could be done is to keep the client queue segregated from the forwarding queue, and make the send task alternate between these queues. I apologize if I seem to have stretched the argument a bit. regards, Avinash On 3/22/07, Philip Levis <[EMAIL PROTECTED]> wrote:
On Mar 22, 2007, at 7:17 PM, Avinash Sridharan wrote: > Hi Phil, > A few more questions more on the bandwidth allocation between the > client and forwarder in the forwarding engine. > > The forwarder effectively has a depth of FORWARD_COUNT (set to 5) > in the FIFO queue and the client has a depth of 1. As you mentioned > in your mail below this implies the client gets only 1/6 th of the > bandwidth. > > Isn't this inherently unfair. In the sense that the forwarded > packets would always get 5 times the bandwidth as compared to the > source itself. I did a simple experiment with the following linear > topology: > > 1<----2<----3 > > This was done on TOSSIM, I kept an application level queue of size > 50 for the forwarder 2. Both 2 and 3 were generating packets that > were destined for the sink 1. > > It turned out that for every 3-5 packets forwarded by node 2 to > node 1 that originated from node 3 you would have a single packet > forwarded sent from node 2 to 1. Thus the bandwidth allocation was > quiet uneven. > CTP is not intended to provide node-level fairness under high bandwidth. If you look closely, none of the protocols that lots of people use do (e.g., MintRoute, etc.). There are a couple of transport protocols that propose ways to do so -- IFRC, Ee's paper in SenSys 2004, ARC in Mobicom 2001. The two general approaches are to maintain per-child state or rate-limit at packet sources. Phil
-- Phd Dept. of Electrical Engineering University of Southern California http://www-scf.usc.edu/~asridhar
_______________________________________________ Tinyos-help mailing list [email protected] https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
