TODO

În calculatoare și comunicații sunt folosite diverse metrici ale echității pentru a determina împărțirea “echitabilă” a resurselor. Am folosit ghilimelele deoarece există mai multe modele conceptuale de echitate, cu alte cuvinte, dreptatea nu este numai una! Problema echității se modelează diferit în funcție de următoarele aspecte:

• utilizatorii cer părți egale, diferite, sau maximul disponibil
• utilizatorii pot utiliza efectiv părți egale sau diferite (e.g: wireless aproape/departe de BS)
• dependența între resursa primită și QoE nu e liniară (e.g: MPEG frames)
• eficiența globală nu este sacrificată prea mult pentru o echitate dorită (e.g: comunism)
• echitatea se obține doar pe termen lung (e.g: WiFi)

În cazul în care toate cererile sunt egale, iar $x_i$ este cantitatea obținută de participantul $i$:

\[ Jain(x_i)=\frac{(\sum_{i=1}^{n}{x_i})^2}{n \sum_{i=1}^{n}{x_i^2}} \] \[ Jain(x_i) \in [0,1] \]

Proprietăți:

• $x_i$ egale $ => Jain(x_i)=1$ echitate perfectă
• $x_1..x_k$ egale și $x_{k+1}..x_n=0 =>$ $Jain(x_i)=\frac{k}{n}$
• $x_1$ ia totul, iar ceilalți nimic '$ => Jain(x_i)=\frac{1}{n}$ - inechitatea cea mai gravă
• independentă de populație
• independentă de dimensiunea $x_i$
• continuă în [0..1]

• capturează inechitatea cea mai gravă
• $ \varepsilon(x) = \frac{\min_i x_i}{\max_i x_i} $
• 0 = starving, 1 = echitate perfectă

Dacă vreți să creați folder nou pe calculatoarele voastre:

git clone https://gitlab.com/b12mihai1/ns-3-dev.git ~/ns-3-dev
cd ~/ns-3-dev
git checkout -b isrm_2020 remotes/origin/isrm_2020
git submodule init
git submodule update --remote --merge
git submodule foreach git pull origin master
./waf configure --build-profile=debug --enable-examples --enable-tests && ./waf build -j4

Dacă folosiți mașina virtuală:

student@isrm-vm:~$  cd ~/ns-3-dev

Verificați că sunteți pe branch-ul isrm_2020 din remote-ul https://gitlab.com/b12mihai1/ns-3-dev.git:

student@isrm-vm:~/ns-3-dev$ git remote -v
origin	https://gitlab.com/b12mihai1/ns-3-dev.git (fetch)
origin	https://gitlab.com/b12mihai1/ns-3-dev.git (push)
 
student@isrm-vm:~/ns-3-dev$ git branch -vv
* isrm_2020 5993ca379 [origin/isrm_2020] fix submodules to have https instead of ssh
  master    da1b41ed1 [origin/master] tcp: Ensure that congestion state is set after every notification

Rulați următoarele comenzi pentru update-ul submodului din examples/ns3-labs:

student@isrm-vm:~/ns-3-dev$ git submodule update --remote --merge

Dacă cea de mai sus nu merge alternativ puteți încerca:

student@isrm-vm:~/ns-3-dev$ git submodule foreach git pull origin master

Topologia din script contine n noduri dintre care n-1 sunt statii, iar ultimul nod este reprezentat de catre access point. Statiile sunt dispuse concentric in jurul access point-ului. Spre exemplu, pentru o topologie cu 4 noduri (3 statii si un access point), CW minim 15, CW maxim 1023, parametrii default de 802.11g, fără PCAP tracing si o durata simulării de 10 secunde, scriptul se ruleaza astfel:

./waf --run "lab9 --minCw=15 --maxCw=1023 --nn=4 --pcap=false --simulationTime=10"

In urma rularii, ultimele 2 linii sunt de interes:

rlen jain eps
3 1 0.999515

rlen reprezinta numarul de statii, jain reprezinta indexul de echitate Jain, iar eps reprezinta indexul de echitate Epsilon.

Rulati scriptul pentru 10 noduri si observati valorile celor 2 indecsi de echitate pentru ferestre CW fixe de 7 vs 4095. Comentați rezultatul.

Comparați echitatea pe termen scurt (1s), mediu(5s), lung (50s) pentru ferestrele CW fixe de 7 vs 4095. Simularea primește parametrul simulationTime pe care îl puteți ajusta.

Pentru ferestre fixe CW = 7, 31, 511, 4095, realizați patru grafice care indică echitatea în funcție de numărul de clienți 2..20. Fiecare grafic conține 3 curbe pentru duratele de rulare (1s, 5s, 50s).

Cum explicați tendințele de creștere/scădere a echității cu: numărul de clienți, dimensiunea ferestrei, scara de timp considerată?

Pentru 802.11 standard cu dimensiunea ferestrei CW variabila minCW=15, maxCW=1023, realizați un grafic care indică echitatea în funcție de numărul de clienți 2..20. Graficul conține 3 curbe pentru duratele de rulare (1s, 5s, 50s).

Cum este echitatea față de cazurile cu fereastră fixă? De ce? ( o exprimare folclorica dinn 802.11, “Rich get richer, poor get poorer”)

Cum se poate îmbunătăți echitatea pentru configurația dată? ¹⁾ Modificați si rulați.

• Utilizarea RTS/CTS duce la creșterea echității? De ce?
• Ce se schimbă atunci când în loc de N fluxuri upstream, avem de exemplu 2 fluxuri downstream și N-2 upstream? ²⁾
• Rezultate
• Echitatea Jain pentru CW = 31
• Echitatea Jain pentru CW = 511
• Echitatea Jain pentru 802.11(CW=31..1023)
• Echitatea Jain pentru 802.11 cu RTS