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

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.

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

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

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

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@web.de
Galileistrasse 30                     Web:   
http://www.detlef-bosau.de
70565 Stuttgart                       Skype: detlef.bosau
Mobile: +49 172 681 9937