Sono stato all’AcaBarcamp organizzato da Fabio Giglietto dove Federico Bo ha presentato la proposta informale di un Corso di Laurea in “Scienze del Web” ispirato alle riflessioni sull’emergenza di una Web Science pubblicate sul numero di luglio di Communications of the ACM da Tim Berners-Lee et al.

Federico Bo definisce le proprie riflessioni un divertissement intellettuale, ma credo che vadano oltre. Al di là del tentativo di definizione di un piano di studi, decisamente prematuro, l’analisi dei fabbisogni e degli obiettivi formativi e l’enumerazione degli ambiti disciplinari coinvolti sono un punto di partenza concreto e promettente.

Trovo inoltre interessante (e nel contesto attuale decisamente confortante e controtendenza) che dall’esterno del mondo accademico Federico Bo riconosca il valore strategico e il vantaggio competitivo che potrebbe derivare dall’istituzione di un corso di laurea in grado di cogliere talmente bene la natura della scienza del web da contribuire concretamente a definirla e a svilupparla.

Seguirò con molto interesse il dibattito che Federico conduce sul suo blog, non solo perchè le discipline di cui mi occupo hanno a che fare con le scienze del web, ma anche per studiare (e magari contribuire ad affinare) i meccanismi con cui un corso di laurea potrebbe effettivamente essere progettato dal basso.

Riferimenti:

• J. Hendler, N. Shadbolt, W. Hall, T. Berners-Lee, and D. Weitzner, “Web science: an interdisciplinary approach to understanding the web“, Commun. ACM 51, 7 (Jul. 2008), 60-69.
• Federico Bo, “Ipotesi per un corso di Laurea in Scienze del Web“, 20 agosto 2008.

Ma se un PC ha già la scheda WiFi, potrebbe usarla anche per comunicare con le proprie periferiche? Gli ostacoli sono due:

1. la stessa scheda di rete non puo’ essere usata contemporaneamente per la connessione di rete e per comunicare in modo diretto con mouse, tastiera e auricolare
2. le schede WiFi consumano troppo per essere installate su periferiche ultraportatili

A superare entrambi gli ostacoli ci ha pensato Ozmo Devices. La soluzione al primo problema è un nuovo driver che permette di usare la stessa scheda di rete WiFi per entrambi gli scopi, la soluzione al secondo problema è il dynamic power management. Il risultato, detto low-power WiFi PAN, è stato presentato in agosto all’Intel Developer Forum.

I primi prodotti saranno disponibili nel 2009. Avranno successo? Dalla loro ci sono’ la compatibilità con gli standard WiFi già supportati dai PC in commercio e la maggior disponibilità di banda rispetto a Bluetooth. Contro c’è la diffusione di periferiche Bluetooth (si stima siano miliardi quelle già in uso). Nel frattempo anche Intel sta lavorando nella stessa direzione.

Riferimenti:

• Steven Cherry, “Wi-Fi Takes On Bluetooth“, IEEE Spectrum, August 2008.
• OZMO Devices, “Ozmo Devices and Avago Technologies Announce Low Power Wi-Fi PAN Optical Mouse Reference Design“, Press release, 18 August 2008.
• Rick Merritt, “Wi-Fi jumps into the PAN“, EE Times, 06 February 2008.

fino a che punto è giusto ammettere eccezioni al principio di neutralità (che impedisce ai provider di discriminare in base all’applicazione, al contenuto e alla provenienza dei pacchetti) per tutelare la sicurezza degli utenti e l’affidabilità delle reti?

In pratica si tratta di trovare il giusto compromesso tra due proprietà delle reti: la neutralità da una parte e la “dignità di fiducia” (per tradurre alla lettera il termine inglese “trustworthiness“) dall’altra. Poichè il dibattito sulla neutralità è ormai centrale, e numerose proposte regolamentari sono già state elaborate, il compromesso sembra dover essere cercato nelle eccezioni alla neutralità tollerate in nome della trustworthiness.

Come al solito ci sono due estremi: regole troppo rigide che rischiano di impedire il raggiungimento di livelli adeguati di sicurezza e affidabilità, regole troppo lasche che rischiano di compromettere la neutralità.

Esempi di regole troppo strette sono quelli delle proposte normative del North Dakota e del Maine, che consentirebbero ai provider di offrire servizi legati alla sicurezza in deroga al principio di neutralità, solo se i singoli utenti hanno la possibilità di rinunciare a tali servizi in nome della neutralità. Norme troppo lasche sono invece quelle che ammettono qualsiasi discriminazione che possa dirsi motivata da ragioni di sicurezza. La questione si fa ulteriormente complessa se le tecniche di tutela della sicurezza richiedono accordi trasparenti tra gli operatori.

In conclusione, Schneider sollecita l’apertura di un dibattito piu’ ampio sull’argomento e suggerisce un procedimento per affrontare il tema della sicurezza sui tavoli della network neutrality:

1. cominciare con l’enumerazione della proprietà di sicurezza e affidabilità che gli utenti della rete potrebbero desiderare,

2. evidenziare quelle per le quali allo stato dell’arte non esistono implementazioni end-to-end,

3. chiedere che le proposte normative sulla network neutrality “non impediscano” lo sviluppo di tecniche atte a garantire le proprietà di sicurezza non altrimenti implementabili.

Riferimenti:

• Fred B. Schneider, “Network Neutrality versus Internet Trustworthiness?”, IEEE Security & Privacy, Vol. 6, No. 4, pp. 3-4, 2008. (pdf)

Il Festival si svolgerà a Urbino dal 10 al 12 ottobre, ma il concorso fotografico è già aperto. Per partecipare basta fotografare scene di vita nel wireless campus, caricarle su Flickr entro il primo ottobre con i tag “conversazionidalbasso, 2008, lwc, uwic” e spargere la voce. Saranno ammesse alla fase finale del concorso le 20 foto che l’8 ottobre avranno raggiunto la maggiore popolarità secondo il ranking di Flickr.

Leggetevi il regolamento e date un’occhiata alle foto in cocorso. Le vostre preferenze saranno determinanti.

Approfitto della splendida ambientazione scelta dagli organizzatori di SENSORCOMM-08 per caricare sul blog un video un po’ più accattivante del solito. In realtà non è solo un pretesto, ma un’antcipazione: dopo la piscina il video inquadra il computer su cui gira la simulazione di un nuovo algoritmo di routing a cui stiamo lavorando e di cui tornero’ a parlare piu’ avanti. L’idea su cui si basa sarà presentata domani al convegno ed è descritta sugli atti di cui riporto un estratto.

Riflessi sullo schermo insieme a me (da sinistra), si vedono Andrea e Saverio. C’è anche Lele, ma non compare perchè è rimasto a presidiare l’ufficio mobile che abbiamo allestito vicino ad una presa elettrica ai tavoli di Le Ciel, Le Soleil e la Mer. L’alimentazione elettrica non è ancora wireless malgrado gli sforzi del MIT…

Per completezza di informazione, l’ambiente di simulazione che compare nel video è OMNeT++.

Riferimenti:

• Copia dell’articolo pubblicato agli atti di SENSORCOMM-08: A. Seraghiti, and A. Bogliolo, “Self-Adapating Maxflow Routing for Autonomous Wireless Sensor Networks”, in Proceedings of SensorComm-08, pp. 360-365, 2008.

A Gianluca va anche riconosciuto il merito di essere stato nei 10 minuti previsti dal programma e da YouTube!

Dal punto di vista pratico ci sono due differenze principali tra ISO/OSI e TCP/IP. La prima è che OSI è un modello di riferimento astratto, mentre il secondo è un’architettura di rete orientata ai protocolli. E’ emblematico che il modello prenda il nome proprio dai suoi protocolli principali: Transmission Control Protocol (TCP) a livello trasporto, e Internet Protocol (IP) a livello rete o internetworking.

La seconda differenza è che Internet ha un numero minore di strati. Volendo allineare gli strati ISO/OSI con gli strati TCP/IP si nota l’accorpamento del livello fisico e data link in un unico livello (detto semplicemente link, o anche host to network), e l’assenza dei livelli sessione e presentazione. L’accorpamento dei primi due livelli è dovuta al fondamentale disinteresse del modello TCP/IP verso tutto cio’ che sta sotto al livello di rete, a cui si richiede di offrire un canale adeguato alla trasmissione di pacchetti IP senza porre vincoli all’eventuale ulteriore stratificazone dei protocolli che lo implementano. I livelli 5 e 6 sono invece assenti perchè ritenuti inessenziali.

La numerazione degli strati comunemente adottata è comunque quella del modello OSI, cosicchè i protocolli di rete sono detti “di livello 3″, quelli di trasporto “di livello 4″, quelli applicazione “di livello 7″ (piu’ raramente di livello 5) e quelli link “di livello 2″ (fatte salve le eventuali sotto-stratificazioni proprie dei protocolli adottati).

Il ruolo dei 4 livelli dello stack TCP/IP puo’ essere sommariamente descritto con riferimento alla comunicazione tra due computer (host) collegati ad una rete i cui nodi intermedi sono detti router. I due host non sono direttamente connessi, e per comunicare devono inviarsi dati lungo cammini che attraversano uno o più router. Chiamiamo A l’host che trasmette e B l’host che spedisce. La rete composta dai soli router è detta subnet.

L’applicazione che gira su A produce i dati e li invia a B lungo un canale virtuale creato dai protocolli di livello inferiore. L’applicazione che gira su B riceve i dati.

Il protocollo di trasporto che gira su A suddivide i dati in pacchetti adatti alla trasmissione in internet e li affida al livello inferiore, mentre quello che gira su B riceve i pacchetti e li riassembla.

Il protocollo di internetworking che gira su A prende ogni pacchetto di dati e decide a quale router inoltrarlo per poterlo alla fine consegnare a B. Il protocollo che gira su B riceve i pacchetti, ne verifica la correttezza e li passa allo strato di trasporto. I protocolli di internetworking che girano sui router intermedi ricevono i pacchetti, ne verificano la correttezza e decidono a quale altro router inviarli per raggiungere la destinazione. In pratica il livello internetworking ha due funzioni principali: routing (o instradamento) e verifica di integrità.

I protocolli di link si incaricano di gestire il collegamento diretto tra nodi adiacenti della rete, garantendo per quanto possibile la corretta trasmissione dei pacchetti. Come già detto il modello TCP/IP è prevalentemente focalizzato sui livelli internet e trasporto, e affida il livello link (o host to network) a qualsiasi protocollo in grado di garantire il collegamento degli host alla rete e l’inivio di pacchetti IP. Tipicamente i protocolli che realizzano lo strato link sono ulteriormente tratificati in due o più livelli: data link logico, MAC, fisico.

Riferimenti:

• La specifica originale del protocollo TCP (V. Cerf, Y. Dalal, C. Sunshine, Specification of Internet Transmission Control Program, RFC 675, 1974) è disponibile sul sito della Internet Engineering Task Force.
• Il primo articolo di Cerf e Kahn (Vinton Cerf, Robert Kahn, A Protocol for Packet Network Intercommunication, IEEE Transactions on Communications, 1974) è scaricabile liberamente da molti siti, tra cui quello della Princeton University.