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

[Detlef Bosau]

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.

>> 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!

Detlef

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