« Robe da matti sulla censura dei libri in USA | Principale | Irresistibile.. le scuse per non fare innovazione nelle telco »

24/10/2013

Commenti

Giuliano Peritore

Fantastico... questo estratto è il più bel testo che ho letto negli ultimi ANNI. Onesto, chiaro, denso di significato, propositivo e contrassegnato dalla usuale elegante modestia di Odlyzko. Da incorniciare. A qualcuno trema la terra sotto i piedi, e non sto parlando delle telco.

Dino Bortolotto

Concordo al 100% nell'ultimo anno mi sono occupato pesantemente di comunicazioni dove NESSUN buffer/cache è funzionalmente possibile/accettabile, nei sistemi di automazione e controllo industriale o TUTTI i messaggi o giungono entro il tempo di ciclo stabilito o anche UN SOLO messaggio giunto fuori del tempo di ciclo stabilito determina il fallimento totale del processo.

Questo è l'unico vero "realtime" e spacciare lo streming video dove sono tollerabili perdite di pacchetti, accelerazioni/decellerazioni, cambi di risoluzione testimonia come sia necessaria la capacita ben piu che il controllo di qualita (QoS) .... a meno che qualcuno non voglia raccontarmi la balla che vuole fare automazione industriale su internet :-)

Gianni

Questo mi pare si ricolleghi alla tesi di Odlyzko che il playback finirà col deventare download. Questo lo trovo comprensibile, i network sono talmete disastrati che uno stream real time si interromperebbe spesso sovente, ne so qualcosa io ultimamente..
Ma in ogni caso osservo pure che il faster than realtime è preferito per video corti.. con video lunghi, molto lunghi ho osservato che anche Youtube fa traffic shaping avvicinando il progressive download più al real time, seppur sempre con un buffer molto generoso.
Quindi presumo che tra le due modalità c'e chi ci guadagna e chi ci perde ma in ceri casi i vantaggi/svantaggi possono anche invertirsi.
Il giorno che tutto sarà in fibra probabilmente queste deatribe saranno discorsi preistorici senza senso....

Gianni

Non sono molto d'accordo. Sull'automazione industriale si, dove certe operazioni vanno fatte in sincro, magari nell'ordine dei centesimi di seconto. Forse è più opportuno usare ISDN o CDN per queste cose dove banda e lantenza sono sempre certi.
Per quel che rigurda QoS nono sono d'accordo, la rete deve essere sempre best effort. QoS lo vedo a livello periferico, tipo router casalingo, dove non vuoi che tuo figlio che si vede l'ultimo della Pixar in ultra high definition, ti mandi a vacche la video conferenza di lavoro, e allora si, QoS sui flussi della conferenza, che è realtime.
Ma a livello di provider, niente deep packet inspection, niente policy QoS altrimenti si sa come si parte ma non si sa come finisce. Chi ti dice che TI non svantaggi YouTube a favore dei suoi servizi di streaming?
E poi, le barzellette del Qos: ultimamente ho aiutato un californiano che gli andava lo streaming video a pause di buffering continuamente.
A me è sembrato da subito un problema di banda, lui insisteva: la mia rete domestica è Gbit il collegamento con il provider è 100Mbit il media server è su una webfarm con cui vado a 100Mbit sicuri, impossibile un problema di banda.
Invece, dopo prove e riprove, era proprio così.. aveva messo una policy QoS nel firewall del server che purtroppo non riconosceva come video gli stream mpeg transport stream... e gli declassava la conessione tcp/ip...

I commenti per questa nota sono chiusi.