Re: [e2e] Ressource Fairness or Througput Fairness, was Re: Opportunistic Scheduling.

Dave Eckhardt wrote:
>> Let's assume a cellular network.
>>
>
> We more or less anti-assumed that, but I'll try to answer the
> question anyway.
>
>

Forgive me :-)

>> Why do we need a scheduler then in the base station?
>>
>
> You probably don't *need* one. But if an error-sensitive scheduler
> would let you undetectably degrade the quality experienced by a
> user in a good spot in exchange for enabling a user in a bad spot
> to "unfairly" (in an air-time sense) get enough quality to keep
> paying you by the minute for his call, you might *want* one.

O.k. You refer to the idea of opportunistic scheduling. That´s what I´m currently thinking about, but this is the next step. Basically, and particularly this should hold true in WLAN (please correct me if I´m wrong) you could maintain an interface queue, as e.g. for Ethernet, and send pending packets in FIFO order. Correct?

> That's
> a possible monetary answer; for LANs one might imagine a sense of
> community supporting the idea of spending a little extra air time
> to help out somebody temporarily in a bad spot (maybe next to a
> microwave oven which will shut off soon).
>
>

Question: Do you make any assumptions about a recovery layer, particularly ARQ, here? I´m not quite sure but I was told, some WLAN settings would employ an ARQ mechanism?

> You could do that by abandoning transmission of the head-of-line packet
> after some amount of time (arguing it is "resource fair" to starve the
> station having trouble to keep the link going).
>
>

Q: Do you think of a stop´n wait ARQ scheme here? This is a basic question, because in a sliding window ARQ scheme, the head-of-line packet would in fact not "stay" at the head of line but would repreatedly occur there again and again. So, it´s no head of line blocking in its literal sense but the effect is the same.

> Or you could fragment packets into link-level frames with different sizes
> and codings for each station depending on its error environment, and then
> round-robin sub-packet frames to stations (you'd need to have N head-of-line
> packets instead of 1, but that should be ok).
>
>

And exactly this introduces a scheduler (round robin). Thus, you have a head of line blocking for one channel where the rest is not blocked. And of course, it makes sense to define a maximum number of transmission attempts, a packet is discarded afterwards.

Do you need help?
In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related postel.org Links end2end-interest Request more information about Pantek

>> Perhaps, I'm a bit nitpicking here. But when I introduce a scheduler at
>> the base station at all, there must be a convincing reason to do so.
>>
>
> An alternative perspective is that if other people have already firmly
> decided to introduce schedulers at base stations we might want to make
> suggestions about better schedulers :-)
>
>

But this is not "pure scientifing" reasoning ;-) Don´t you agree? ;-)

>> Back to the cellular network.
>>
>> So, how do we integrate such a cell with a base station with a scheduler
>> and a number of terminals into the big picture of
>> - best effort
>> - asynchronous
>> - in many cases self clocked
>> - end to end traffic ?
>>
>
> I'm not sure I understand the question... in CDMA networks (coming soon
> to a GSM phone near you!) soft handoff already means there is a level
> of coordination above the "base station".
>
>

Of course, but I intendedly ignore this for the moment. This is in fact not that unrealistic, as I´m thinking particularly of HSDPA, where (I don´t know what the marketing people say) you cannot move too fast, if you want to exploit maximum capacity. One (alleged ;-)) idea in HSDPA is to exploit multi user diversity by harnessing the microscopic fading. And that becomes the more difficult the faster you move. So, I´m thinking of velocities between 1 to 10 meters a second. Therefore, you shouldn´t have to roam that often.

(And you´re perfectly right, other persons have decided to use a scheduler here and it´s an interesting challenge to think whether there are better ones than those actually used ;-))
>> At the moment, I think a ressource fair scheduler at the base station
>> would be the best solution to do this.
>>
>
> We hope the paper argues that effort-fair (== "resource fair") is "fair"
> but undesirable in some situations, that outcome-fair is "fair" but
> undesirable in other situations, and that a hybrid notion of fairness
> is both desirable and achievable.
>
>

That´s at least a much better position than "purely throughput fair (= "outcome fair") which I think is widely used at the moment.

> Dave Eckhardt
>
> P.S. There is further material in my dissertation, including a warning
> about the difficulty of measuring per-station conditions when trying
> to do scheduling.
>

Is this available somehow? Could you give me a link?

Thanks!

Do you need more help?
In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related postel.org Links end2end-interest Request more information about Pantek

Detlef

-- 
Detlef Bosau                          Mail:  detlef.bosau@web.de
Galileistrasse 30                     Web:   
http://www.detlef-bosau.de
70565 Stuttgart                       Skype: detlef.bosau
Mobile: +49 172 681 9937