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

[Detlef Bosau]

Dave Eckhardt wrote:
>> Do we talk about ressource fairness?
>> Or do we talk about throughput fairness?
>>     
>
> It is possible to do both, in a balanced way.  Some time back
> we did some initial thinking about that.
>
>   D. Eckhardt, P. Steenkiste.
>   Effort-limited Fair (ELF) Scheduling for Wireless Networks.
>   http://www.cs.cmu.edu/~davide/papers/INFOCOM2000.pdf
>   (erratum: In Section VI, the crossover error rate is 55%, not 50%)
>
> Dave Eckhardt
>   

I just read your paper and get somewhat lost in the use of
- bandwidth,
- capacity,
- throughput,
- capacity loss,
- ...

It is just an observation of mine, that these terms are somewhat 
polymorphic, particularly when they are used by CS and EE people. And I 
personaly think, this is a very serious issue as it is often hardly 
possible to communicate at all between these disciplines...

Just a very premature observation.

And now for something completely different: Scheduling.

Sometimes, I get the impression they were three kinds of engineers 
dealing with networks.

1.: CS / packet switching guys, which basically don´t know about 
scheduling in communication networks.
Packets are stored in a FIFO queue and that´s it.

2.: EE/ telco / line swichting guys, which basically can´t imagine 
anything else than scheduling,
they have congenital schedulers inside.

3.: Multimedia / DiffServ / IntServ/ QoS guys, who are something in 
between :-)

O.k. I belong to the first category. (And I strongly don´t belong to the 
third, even more after having got in touch with multimedia over wireless 
networks.)

So, just for my understanding I raise a perhaps stupid question:

Let´s assume a cellular network. Why do we need a scheduler then in the 
base station? (I once asked this an EE guy and got no answer...)

Basically, I see exactly one reason: In networks which require a link 
layer recovery mechanism and where the BS-Terminal links suffer from 
very different error rates, we need a mechanism which prevents 
starvation problems and head of line blocking.

Particularly the link layer recovery may insert traffic which must be 
served before any other traffic for flow control reasons: Unacknowledged 
data occupies memory at the sender. In addition incomplete L3 packets 
occupy memory at the receiver, particularly becaause incomplete packets 
cannot be handed to the application. The worst case is that a receiver 
cannot receive additional data in order to have packets completed and 
cannot pass packets to the application, so there is a dead lock 
situation. Therefore, retransmissions are given higher priority then 
first / new transmissions.

Is this correct?

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. And 
I only found the aforementioned one...

O.k.

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 ?

At the moment, I think a ressource fair scheduler at the base station 
would be the best solution to do this.

What do you think?

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