Hi Phil, By service rates of a packet I mean the service rate that the queue is giving to each packet. Since the buffer space for the clients and the forwarders are different the probability that you serve a client packet should be lower then the probability that you serve a forwarded packet (assuming both are generating packets at the same rate).
I agree fairness is at the flow level but the fair rates that you would calculate for each flow is closely tied to the maximum possible rate that each flow can be serviced at, which in turn is determined by the queuing dynamics. This reasoning leads to my statement " that there seems to be an inherent unfairness in the queuing dynamics ". Also under light loads the above affects might not show up as you stated since if the average queue length of the forwarded packets is going to be close to 1 then all the above dynamics I just described wouldn't come into play. But again this would depend on what you define a "light" load as (what if the average queue length is greater than 1 ?). My objective here was to develop a rate control mechanism on top of the CTP framework and the rates that I was calculating was based on the notion that all flows are treated the same in the queues. However as I mentioned earlier the rates I was getting were coming out to be disproportional, but I concede that the experiments were being carried out at heavy load (all queues were almost fully loaded). regards, Avinash On 3/23/07, Philip Levis <[EMAIL PROTECTED]> wrote:
On Mar 23, 2007, at 9:11 AM, Avinash Sridharan wrote: > Hi Phil, > I agree that if you apply rate control to the client it would > limit the packet generation, but the reason I say the queueing > dynamics would override these affects is that rate control > algorithm assume all packets have the same service rate. I don't understand what you mean by "all packets have the same service rate." Fairness rarely operates in terms of packets; it operates in terms of flows or node pairs. I'm not sure what fair servicing on a packet basis means, as a packet is a singleton. > But since the queue is biased towards the forwarder the service > rate of a client packet will be less than the service rate of a > frowarded packet. Wouldn't the rate allocated to the client have to > take this into account ? Again, I don't understand what you're asking. Are you asking about how you would implement network fairness? Or are you commenting that the current implementation of CtpForwardingEngineP does not have commands/events which provide the information you would need to implement fairness? This latter point is true -- you need to at least see the queue depth. Rodrigo and Om are working on the implementation so it can provide this information, in order to allow transport-level fairness mechanisms (e.g., IFRC) to be built on top of a CTP topology. I don't understand what you're trying to achieve that CTP won't let you. I'll reiterate -- CTP has never claimed to provide network fairness under high load. If anything, it focuses on the much more common case in *low-power* sensornets of light load. > I agree with the point you made on the segregation of queues its > like applying a control algorithm on the queues itself. So would it > make sense to have a single queue for clients and forwarded packets > and serving them without bias (first come first serve) and allowing > rate controllers to control their rates ? Sure -- isn't that what I said originally? 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
