Andrew Odlyzko, che mi onora della sua amicizia, ha appena pubblicato
questo articolo. che consiglio a tutti di leggere. solo un estratto sotto:
questo articolo. che consiglio a tutti di leggere. solo un estratto sotto:
Will smart pricing finally take off?, A. Odlyzko
True streaming video is, and will remain, a very small fraction of traffic.
Video does dominate current Internet traffic by volume, but it is almost exclusively transmitted as faster-than-real-time progressive downloads. That is the only method that makes sense technologically. (Video conferencing is completely different, but we now have enough experience to be able to predict with safety that it will not be contributing giant amounts of traffic.) Furthermore, this was easily predictable and was predicted a long time ago.
George Gilder wrote about it two decades ago, for example, and he attributes the idea to Nicholas Negroponte even earlier. Their prediction has come true, yet almost everyone thinks that the floods of video they consume are true streaming video. This skewes business decisions and public policy discussions, since networks dominated by real-time long-lived data flows of predictable size and with tight latency constraints do indeed lend themselves to many of the pricing and network management techniques that are so beloved by both top managers and telecom researchers, cf. [40].
The myth of real-time streaming video is so pervasive and strong that it also affects networking researchers. For the last decade, this author has been taking polls asking those in the audience to raise their hands if they saw any advantage at all, for anyone, in transmitting video faster than real time. Usually, even among networking researchers, at most 10% have responded. The highest positive response rates were around 40%, among a couple of audiences packed with researchers working on wireless ad-hoc networks, who understand that on connectivity being maintained, but can use buffers to compensate. (While one can envisage ultra-reliable wired networks, in the wireless arena this is simply not achievable,there are far too many unpredictable sources of impairments.)
This demonstrates that even networking researchers don’t know what is happening in today’s networks, nor why it is happening.
The preoccupation with real-time streaming video leads to the constant questioning about the potential demand for high speed access. Who needs gigabit to the home, is being asked, since the most that most observers can imagine is a few streams that might possibly come to 20 Mbps each in some future high-definition TV. This perfectly illustrates the lack of vision not just on the future, but on the present, that afflicts this industry. After all, why are people buying 300 Mbps home WiFi access points, if all they are after is streaming a few movies? Yet such routers are selling, and high speed home access is also selling (when offered at reasonable cost), because they allow for low transaction latency
...
Substantial improvements in [wireless] capacity could be achieved just by building more facilities, but that would require greatly increased capital spending. That could come from either higher revenues from users, or from restructuring the industry so it spends less on marketing, lobbying, and other activities, and more on construction. Since neither is likely to happen, we are likely to see traffic limited by available capacity. Combined with the wide disparity of various types of bits, this suggests that pricing will play a significant role in balancing demand and supply
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.
Scritto da: Giuliano Peritore | 25/10/2013 a 08:51
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 :-)
Scritto da: Dino Bortolotto | 25/10/2013 a 15:58
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....
Scritto da: Gianni | 26/10/2013 a 20:13
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...
Scritto da: Gianni | 27/10/2013 a 09:07