wiki:Diario/SoujaK

Version 8 (modified by soujak, 17 years ago) (diff)

Aggiornamento.

Diario di SoujaK

  1. Diario di SoujaK
    1. 4 Giugno 2007
    2. 5 Giugno 2007
    3. 11 Giugno 2007
    4. 12 Giugno 2007
    5. 13 Giugno 2007
    6. 13 Giugno 2007
    7. Documentazione
    8. Link Utili

4 Giugno 2007

Strumenti di lavoro su XT3: creazione del gruppo e dell'alias 'tirocinio07', inizializzazione dell'ambiente Trac e del repository Subversion (2h).

5 Giugno 2007

Strumenti di lavoro su XT3: messa a punto dell'autenticazione sul server web (1h).

11 Giugno 2007

Sincronizzazione del diario della settimana scorsa, inizializzazione della pagina wiki della Milestone di rilevamento del carico. (0.4h)

00: l'articolo propone l'identificazione di una bandwidth potenziale ottenibile da un determinato AP a partire dalle condizioni di carico che un client è in grado di rilevare in esso. Lo studio prende in considerazione uno scenario privo di disturbi ambientali, senza coordinamento centralizzato. Assumendo che i frame beacon non abbiano priorità sugli altri, è possibile stimare il tempo medio di attesa di trasmissione osservando il ritardo dei frame beacon (si ricordi la presenza del "Beacon Interval" e del "Target Beacon Transmission Time"). Inoltre fornisce spunti perché una stazione possa inferire una probabilità di perdita di trasmissioni, sfruttando i numeri di sequenza ("Sequence number") dei frame che cattura e il "Retry Bit". La veridicità delle conclusioni dipende dalla veridicità delle assunzioni poste e dalla generalità dell'hardware utilizzato per le sperimentazioni effettuate (1400-1740).

01: La selezione ottimale dell'Access Point è strettamente legata a politiche di allocazione del traffico in grado di gestire in maniera ottimizzata le risorse disponibili. Il problema viene affrontato da un punto di vista piuttosto teorico, oltre che distante dai nostri scopi, rendendolo quasi per nulla interessante. (1800-1820, 1900-1920)

02: L'articolo propone parametri concreti per la valutazione della bontà degli AP, che prevede essere calcolati direttamente dal loro firmware(testato con IPW 2915) e periodicamente comunicati alle STA tramite i frame beacon. Nonostante la forte dipendenza da modifiche ai firmware presumo che i calcoli dei parametri, di davvero grande rilevanza, effettuati dagli AP possano essere eseguiti anche lato client. (1920-2000, 0910-0930)

12 Giugno 2007

1000-1020 (0.33h)
Sincronizzazione del diario.

1030-1100 (0.50h)
Punto della situazione assieme a gnappo.

1120-1155 (0.58h)
03: In appendice è presente un'interessante calcolo dell'impatto degli errori di trasmissione sulle prestazioni, calcolando diligentemente i dettagli relativi ai backoff incrementali.

1210-1310 (1.00h)
04: Lo studio effettua una stima dell'effettiva bandwitdth disponibile, in base al tempo che intercorre fra la richiesta di invio del frame e la notifica di avvenuta trasmissione. In questo calcolo vengono a sommarsi i tempi di attesa per l'accesso al mezzo (rilevazione di mezzo disponibile e successiva contesa), la procedura RTS/CTS, l'effettiva trasmissione dei dati e del'ACK, IFS relativi. Questa bandwidth e` fortemente influenzata dalla dimensione dei frame e viene quindi normalizzata rispetto ad un frame di riferimento per avere una misura da essa indipendente. Lo studio proseguirebbe su politiche di ammissione di una STA in un BSS, formalizzando il concetto di proporzione del tempo del canale (CTP, Channel Time Proportion) di un determinato flusso dati, ottenibile dal rapporto fra la bandwitdth direttamente richiesta dal flusso e la bandwitdth disponibile appena citata. I concetti appena descritti appaiono come spunti piuttosto rilevanti ai nostri fini.

1450-1617 (0.45h)
Ricerche ulteriori.

1650-1720 (0.33h)
05: L'articolo propone una algoritmo di controllo della associazione (lato client) che si configura come erede degli algoritmi precedentemente proposti da altri studi.

13 Giugno 2007

0900-0910 (0.16h)
Approfondimento di 04.

1000-1025 (0.41h)
Sincronizzazione del diario.

1025-1140 (1.25h)
05: Lo studio ha come fine l'ottimizzazione delle risorse, intese in senso globale e propone un algoritmo per la gestione delle associazioni basato sul rilevamento del carico degli AP. Il concetto di carico totale di un AP viene definito come la somma dei carichi di ogni singolo client, i.e. il tempo che un AP impiega per fornire ad ognuno degli utenti una unità di traffico mentre. Questa definizione, in realtà scopiazzata da 06, viene successivamente arriccchita, definendola piuttosto come sommatoria degli inversi dei tassi di trasmissione di ogni client associato ad un determinato AP. In pratica si calcola il tempo necessario affinché ognuna delle stazioni associate con l'AP in questione trasmettano una unità di dati, supponendo che esse abbiano sempre dati in attesa di invio. Così facendo si definisce il concetto di tasso di trasmissione ottenibile (attainable data rate), parametro fondamentale per l'algoritmo di associazione che viene proposto.

1220-1330
Amministrazione su argon.

1500-1520 (0.33h)
Punto della situazione con gnappo.

1520-1605 (0.75h)
05: L'algoritmo per il controllo dell'associazione che viene proposto tiene conto della presenza di congestioni, dal momento che il massimo tasso trasmissivo ottenibile non può che essere influenzato da questa eventualità. Propone inoltre che il client effettui rilevazioni sui carichi degli AP disponibili non solo nei momenti di necessità (non ancora associato), ma anche a intervalli regolari (già associato) per individuare alternative sempre migliori. Questo tipo di approccio risulta quantomai interessante nella prospettiva di avere a disposizione, come nel nostro caso, una molteplicità di dispositivi 802.11.

1605-1715 (1.16h))
06: Lo studio si propone quantomeno come la fondazione teorica di una politica di allocazione delle risorse equa min-max (min-max fairness) e bilanciata che intende essere la più vicina all'ottimo (perché il problema sarebbe NP-hard). Per equità max-min si intende una situazione nella quale non vi è modo per fornire bandwidth addizionale ad un client senza doverne togliere almeno altrettanta a qualche altro. Lo studio formalizza in maniera rigorosa il concetto di carico di un AP.

13 Giugno 2007

1110-1235 (1.41h)
06: La definizione di equità max-min è stata approfondita in tutta la sua complessità che la definizione formale esprime, facendo emergere spunti utili non alla milestone attuale ma a possibili politiche di bilanciamento del carico, eventualmente rilevanti per la scelta dell'AP a cui associarsi.

1300-1330 (0.50h)
06: La definizione di carico che l'articolo propone è allineata al resto dalla letteratura informatica. Informalmente il carico dell'AP a indotto da una STA s è l'inverso del bitrate effettivo che s rileva, normalizzato rispetto allo specifico peso della STA. Il carico di a è poi il massimo fra le due sommatorie di tutti i carichi indotti da tutte le associazioni effettive (che, cioé, producono un bitrate non nullo), la prima sui bitrate dei collegamenti AP-STA, la seconda sui bitrate del collegamento AP-ReteEsterna.

1330-1347 (0.28h)
Aggiornamenti su Trac: scritta la descrizione della milestone e gli appunti sul lavoro della mattinata.

1420-1511 (0.88h)
06: Lo studio spende energie non indifferenti (considera infatti anche situazioni che tengano presente il carico su un insieme di AP) per dimostrare con rigore teoremi e proprietà che sono indispensabili alla dimostrazione dello stretto legame che intercorre fra una scelta di associazioni bilanciate min-max e una scelta di allocazione della bandwidth che sia equa max-min. Quest'ultimo teorema, oltre che essere sprovvisto di una dimostrazione completa, è non soddisfatto nel caso di associazioni singole.
L'articolo prosegue per strade che mi sono parse allontanarsi sempre più dai nostri interessi, ma tengo a sottolineare i risultati che gli autori hanno ottenuto durante una simulazione di confronto fra le più note politiche di gestione dell'associazione. Lo schema proposto non solo supera di un 20% il throughput del metodo SSF (Strongest Signal First), intuitivamente lontano dall'ottimo, ma arriva al triplo di quello di LLF (Least Loaded First)! Terrei quindi presente la possibiltà di riprendere in mano il documento per comprendere meglio l'algoritmo di bilanciamento (che, spaventato dalla complessità, non ho analizzato) o per mettere in dubbio l'attendibilità dei risultati delle simulazioni.

Documentazione

Link Utili