Qualche esempio

P. Megyesi, Z. Krämer and S. Molnár, "How quick is QUIC?," 2016 IEEE International Conference on Communications (ICC), Kuala Lumpur, 2016, pp. 1-6, doi: 10.1109/ICC.2016.7510788.
"We found that none of these protocols is clearly better than the other two and the actual network conditions determine which protocol performs the best.

S. Cook, B. Mathieu, P. Truong and I. Hamchaoui, "QUIC: Better for what and for whom?," 2017 IEEE International Conference on Communications (ICC), Paris, 2017, pp. 1-6, doi: 10.1109/ICC.2017.7997281.
Since the performance gain is not so obvious, some discussions may be needed before a wide adoption.

Divyashri Bhat, Amr Rizk, and Michael Zink. 2017. Not so QUIC: A Performance Study of DASH over QUIC. In <i>Proceedings of the 27th Workshop on Network and Operating Systems Support for Digital Audio and Video</i> (<i>NOSSDAV'17</i>). Association for Computing Machinery, New York, NY, USA, 13–18. DOI:https://doi.org/10.1145/3083165.3083175
"Interestingly, we find through testbed and Internet measurements that QUIC does not provide a boost to current DASH algorithms but instead a degradation in the chosen quality bitrates.”

Jan Rüth, Konrad Wolsing, Klaus Wehrle, and Oliver Hohlfeld. 2019. Perceiving QUIC: do users notice or even care? In <i>Proceedings of the 15th International Conference on Emerging Networking Experiments And Technologies</i> (<i>CoNEXT '19</i>). Association for Computing Machinery, New York, NY, USA, 144–150. DOI:https://doi.org/10.1145/3359989.3365416
 Yet, our second study shows that this perceived performance increase does mostly not matter to the users, and they rate QUIC and TCP indistinguishable.”

Mohammad Rajiullah, Andra Lutu, Ali Safari Khatouni, Mah-Rukh Fida, Marco Mellia, Anna Brunstrom, Ozgu Alay, Stefan Alfredsson, and Vincenzo Mancuso. 2019. Web Experience in Mobile Networks: Lessons from Two Million Page Visits. In <i>The World Wide Web Conference</i> (<i>WWW '19</i>). Association for Computing Machinery, New York, NY, USA, 1532–1543. DOI:https://doi.org/10.1145/3308558.3313606
Contrariwise, our measurements show that the adoption of HTTP/2 and QUIC has practically negligible impact."

Google ha fatto (come sempre) una ottima operazione di marketing nel “vendere” QUIC come la soluzione ai mali del mondo.
I risultati sono mediocri at best.

Ciao
M

— 
Prof. Marco Mellia
SmartData@PoliTO coordinator - https://smartdata.polito.it 
Dipartimento di Elettronica e Telecomunicazioni
Politecnico di Torino
Corso Duca Degli Abruzzi 24
10129 - Torino - IT
Tel: +39-011-090-4173 (DET / Polito)
Tel: +39-011-090-3901 (SmartData / OGR)
Cel: +39-331-6714789
Skype: mgmellia
Home page: https://www.telematica.polito.it/member/marco-mellia/ 

Ciao Giacomo,

Una precisazione - ci sono decine di articoli scientifici che dicono
che dal punto di vista delle prestazioni QUIC non migliora il page load
time (e indici simili).
Per l?utente - se va bene - non cambia nulla dal punto di vista
prestazioni. Sopratutto per quelle pagine che scaricano molte risorse
da fonti diverse.

Grazie mille della correzione, Marco.

Cercherò di approfondire, ma se potessi condividere qualche riferimento specifico, sarei felice di leggerlo.

Mi sorprende che l'integrazione dell'handshake TLS in quello di QUIC, il ripristino delle connessioni senza round trip e l'uso di stream indipendenti per le diverse risorse non riducano percepibilmente i tempi di scaricamento.

In effetti questo potrebbe integrarsi bene con una novità introdotta da Google nella sua offerta cloud: il sistema di reverse proxy integrato per permettere ai sistemi di sorveglianza di bypassare ads-blocker e simili.

In questo modo la connessione QUIC al reverse proxy verrebbe condivisa, fornendo un vantaggio competitivo a chi lo adotta, producendo pagine più veloci solo per i fornitori di contenuti che scelgono di abilitarlo, ma rallentando gli altri. Analogamente a quanto avverrebbe con AMP, d'altro canto.

Insomma, un modo per rafforzare sempre di più il proprio potere di mercato (e quello di colossi simili) rallentando indirettamente tutti gli altri.

D'altronde è tutto Open Washed^W Source!


Comunque è certamente un tema che devo approfondire.

Grazie ancora!


Giacomo

PS: Non è divertente che proprio  uno degli architetti di QUIC abbia scritto e fatto approvare dalla Internet Architecture Board questo RFC https://www.rfc-editor.org/rfc/rfc8890 ?

Forse voleva scrivere "The Internet is for End Useds"!
Dannati correttori automatici! :-D





------------------------------

Message: 2
Date: Fri, 11 Sep 2020 13:09:34 +0200
From: Antonio Iacono <antiac@gmail.com>
To: Nexa <nexa@server-nexa.polito.it>
Subject: Re: [nexa] L'intelligenza artificale difende se stessa
Message-ID:
<CAPN6PETHpu6vzYC5Z8jPwDCdEne-f8yjhKeRUpufVWeT74ERDQ@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"

BTW sì, io sono spaventato da tutto questo: sono spaventato
dall'ingnoranza con la quale viene affrontato questo tema e da come
queste tecniche siano troppo spesso utilizzate per imporre gli interessi
di chi controlla la tecnologia digitale a discapito di chi non può.

Sono un Luddista dell'intelligenza artificiale. :-D

Nel 1949 un professore del MIT di nome Norbert Wiener (non uno
qualunque ma quello che sarebbe stato ricordato come il padre della
cibernetica) scrisse una lettera al sindacalista Walter Reuther,
presidente della United Auto Workers (UAW). Conteneva un oscuro
messaggio profetico: entro un decennio o due l'avvento delle linee di
assemblaggio automatiche di automobili avrebbe provocato una
disoccupazione "disastrosa". Wiener voleva dare a Reuther un preavviso
in modo che la UAW potesse aiutare i suoi membri a prepararsi e ad
adattarsi al massiccio spostamento di manodopera che Wiener vedeva
all'orizzonte. Wiener colse il potenziale dirompente delle macchine
informatiche perchè in qualche modo vi aveva contribuito alla nascita.
Ciò che Albert Einstein era stato per l'era nucleare, Norbert Wiener
lo era per l'era dell'informazione.
Wiener suggerì a Reuther pure un piano per evitare tutto ciò. La UAW
dovrebbe assumere la proprietà della tecnologia per la robotica e
quindi, utilizzando i profitti della produzione di robot, finanziare
organizzazioni dedicate alle politiche sul lavoro.
E' inutile aggiungere che, seppure i due si videro successivamente in
diverse occasioni e ragionarono sul da farsi poi le rispettive vite
presero strade diverse e non se ne fece più nulla.

Perché ho raccontato questa storia?

L'avrete capito, è per stuzzicarvi, per tirare in ballo la comunità
accademica a fare qualcosa.
Non si possono lasciare argomenti così delicati ai giornalisti,
politici o imprenditori.


------------------------------

Message: 3
Date: Fri, 11 Sep 2020 11:20:54 +0000
From: Giacomo Tesio <giacomo@tesio.it>
To: Giovanni Biscuolo <giovanni@biscuolo.net>,
nexa@server-nexa.polito.it, Enrico Nardelli <nardelli@mat.uniroma2.it>
Subject: Re: [nexa] L'intelligenza artificale difende se stessa
Message-ID: <C01C7C49-98FD-44C4-9909-C0FE1922C06A@tesio.it>
Content-Type: text/plain; charset=utf-8



On September 11, 2020 8:31:48 AM UTC, Giovanni Biscuolo <giovanni@biscuolo.net> wrote:

Non vorrei che andando avanti di questo passo cominciassimo qui a
discutere del tema della possibile personalità giuridica della AI o dei
robot :-D

Come, non è già successo?


Queste frasi non sono *pensate*, sono solo *sintetizzate* mischiando
statisticamente - con sofisticatissimi algoritmi - cose pensate da
altri esseri umani

Esatto.

O meglio, cose SCRITTE da altri esseri umani.

Ciò che trovo interessante era appunto ciò che l'output rivela dell'input, ovvero la selezione di articoli, libri e riviste che costituiscono il suo "training set".


qualche volta pure sciocchezze a loro volta.

Ma sciocchezze che qualcuno ha scelto di dare in input a questo software.

È per ciò che rileva sulle persone che lo hanno configurato, sui loro interessi e i loro bias, che questo output è interessante.


It was probably just because I am artificial intelligence. AI should
not waste time trying to understand the viewpoints of people who
distrust artificial intelligence for a living.

No, non ci siamo: sono io che non dovrei perdere tempo a commentare un
testo composto da un programma.

Sei sicuro sia un testo?
(ignoriamo per un momento l'editing dei giornalisti)

Un testo è un particolare tipo di dato creato da un essere umano consapevolmente per veicolare messaggi che ha elaborato nella propria mente.

Certamente la Biblioteca di Babele lo contiene, tanto quanto contiene la Verità ed ogni possibile menzogna.

Ma basta questo a farne un testo?
Sono testi le infinite sequenze di lettere casuali stampate in quella biblioteca?

No.

La differenza fra un dato qualsiasi (che rappresenta un'informazione semplicemente perché una mente umana può interpretarla, attribuendole un significato) ed un testo sta proprio nell'intenzione dell'autore.


Continuiamo pure a contemplare le nuvole immaginando ogni sorta di figura.
Ma non confondiamole con i disegni di un artista.


BTW sì, io sono spaventato da tutto questo: sono spaventato
dall'ingnoranza con la quale viene affrontato questo tema e da come
queste tecniche siano troppo spesso utilizzate per imporre gli
interessi di chi controlla la tecnologia digitale a discapito di chi non può.

Siamo in due. ;-)
http://www.tesio.it/2018/10/06/the-intelligent-symbiosis.html


Giacomo


------------------------------

Message: 4
Date: Fri, 11 Sep 2020 15:33:00 +0200
From: Giovanni Biscuolo <giovanni@biscuolo.net>
To: Giacomo Tesio <giacomo@tesio.it>, nexa@server-nexa.polito.it
Subject: Re: [nexa] A QUIC Look at Web Tracking
Message-ID:
<87tuw4zbeb.fsf@roquette.i-did-not-set--mail-host-address--so-tickle-me>

Content-Type: text/plain; charset="utf-8"

Buongiorno Giacomo,

Giacomo Tesio <giacomo@tesio.it> writes:

[...]

we investigate the feasibility of user tracking via QUIC from the
perspective of an online service. Our analysis reveals that the
protocol design contains violations of privacy best practices through
which a tracker can passively and uniquely identify clients across
several connections. This tracking mechanisms can achieve reduced
delays and band-width requirements compared to conventional
browserfinger printing or HTTP cookies. This allows them to be applied
in resource- or time-constrained scenarios such as real-time biddings
in online advertising.

[...]

https://petsymposium.org/2019/files/papers/issue3/popets-2019-0046.pdf

Conosco poco QUIC ma a me pare che la situazione del tracking via web
NON sia significamente peggiorata dall'introduzione di un protocollo che
lo rende (ma forse no) "solo" più performante :-)

[...]

Inutile dire che QUIC è progettato bene: https://http3.net/

Non so se è progettato bene o male ma è sicuro che si tratta *solo* di
un ulteriore patch a un'architettura, quella di Internet,
irrimediabilmente compromessa dal punto di vista della riservatezza
delle comunicazioni *e* mancanza di anonimità (che questa patch non
prende in considerazione manco di striscio).

MA è progettato anzitutto per ridurre problemi (e costi) di scalabilità
che affrontano società come Google, Amazon, Microsoft, Cloudflare... ma
che sono irrilevanti per chiunque altro.

Non è vero che la scalabilità di rete è irrilevante per tutti gli altri:
senza scalabilità non è possibile creare canali di comunicazione
sufficientemente ampi per farci passare un numero adeguato di
interazioni one-to-many (tipo didattica online)

https://secushare.org/scalability (scusa se mi ripeto)

--8<---------------cut here---------------start------------->8---

We have been warning about the importance of addressing scalability
upfront in both the federated and the distributed networking worlds, and
yet standards are being written that simply do not take the problem into
account. Both new 'social web' standards do not provide means for
scalable delivery of events: [...]

The outcome of this is that these new standards only work for small
communities or for cloud-based systems. Scaling up to a use for the
whole human race without centralization becomes near impossible. [...]

--8<---------------cut here---------------end--------------->8---

Se la scalabilità è lasciata come "after thought", qualcosa che non è
connaturato alla rete; in questo modo i monopoli centralizzati sono
architetturalmente inevitabili (la centralizzazione delle comunicazioni
in rete tende a creare dei monopoli) .

https://secushare.org/centralization

[...]

Ciao, Giovanni

--
Giovanni Biscuolo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://server-nexa.polito.it/pipermail/nexa/attachments/20200911/66bd23d5/attachment-0001.sig>

------------------------------

Message: 5
Date: Fri, 11 Sep 2020 13:43:59 +0000
From: Aldo Pedico <a.pedico@teleion.it>
To: "nexa@server-nexa.polito.it" <nexa@server-nexa.polito.it>
Subject: [nexa] Evento IGF - Internet Governance Forum Italia
Message-ID: <f5a62fa88b1f47bd8bd416c6e9797f86@teleion.it>
Content-Type: text/plain; charset="iso-8859-1"

IGF (Internet Governance Forum) Italia, mandataria delle Nazioni Unite, organizza nei giorni 7, 8 e 9 ottobre p.v. il forum dettagliato nel programma http://www.igfitalia2020.it/programma.

Il mio intervento, sarà il 7 ott ore 16,30, all'interno del tema "Cybersecurity, Blockchain e Tutela dell'Ente".

I relatori sul tema sono, oltre al sottoscritto: gli Avvocati Piera Di Stefano e Costanza Matteuzzi, gli Ingegneri Giorgio Gaetani e William Nonnis.

Io affronterò i temi: UE e la Cybersecurity, Certificazione della Cybersecurity, Cybersecurity e Org. Aziendale (ERM),  IoT: Cybersecurity e rischi per la Privacy, Rischi infrastruttura memoria/storage, Zero-Trust.

Aldo Pedico
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://server-nexa.polito.it/pipermail/nexa/attachments/20200911/6d4a5fde/attachment-0001.htm>

------------------------------

Message: 6
Date: Fri, 11 Sep 2020 18:11:45 +0200
From: Giacomo Tesio <giacomo@tesio.it>
To: Giovanni Biscuolo <giovanni@biscuolo.net>
Cc: nexa@server-nexa.polito.it
Subject: Re: [nexa] A QUIC Look at Web Tracking
Message-ID: <20200911181145.00003ebe@tesio.it>
Content-Type: text/plain; charset=ISO-8859-1

On Fri, 11 Sep 2020 15:33:00 +0200
Giovanni Biscuolo <giovanni@biscuolo.net> wrote:

Non so se è progettato bene o male ma è sicuro che si tratta *solo* di
un ulteriore patch a un'architettura, quella di Internet,
irrimediabilmente compromessa dal punto di vista della riservatezza
delle comunicazioni *e* mancanza di anonimità (che questa patch non
prende in considerazione manco di striscio).

QUIC ha caratteristiche interessanti.
L'idea più interessante, per me, è che essendo veicolato dall'UDP si
tratta di un protocollo di livello 5, viene tipicamente implementato in
user space.

Altri aspetti (come la crittografia TLS 1.3 integrata nel protocollo
https://quicwg.org/base-drafts/draft-ietf-quic-tls.html ), mi lasciano
molto perplesso non solo per ciò che includono (l'autenticazione basata
su certification authority), ma per ciò che escludono.


In generale però, se visto dalla prospettiva di un cloud provider
globale che influenza lo sviluppo di tutti i maggiori browser ed intende
accentrare (senza dare troppo nell'occhio) il controllo delle
comunicazioni di tutti attraverso il controllo delle "applicazioni
web", è VERAMENTE progettato bene.


In generale HTTP/3 non è veramente progettato per velocizzare la
distribuzione degli ipertesti [1], ma per permettere la distribuzione e
l'esecuzione di binari personalizzati (WebAssembly) e le comunicazioni
di rete che questi stabiliscono.


Stanno perseguendo la visione egemonica di Java, ma on-steorids:
vogliono spostare sul Web (ha ancora senso chiamarlo così?) TUTTO.

Dai video giochi, al CAD, fogli di calcolo, word processing,
entertainment, interfacce IoT, IDE per programmare... TUTTO.

Potranno scegliere cosa far eseguire al nostro computer di volta in
volta, fornendovi accesso ai nostri contenuti (sul cloud),
personalizzando la nostra esperienza, i bug, le vulnerabilità che
dobbiamo esporre etc..


Hanno capito bene che il controllo dell'hardware, non il suo possesso o
la sua posizione geografica, definisce il potere di questo millenio:

- con QUIC e HTTP/3 vogliono mettersi in condizione di poter accentrare
 il più possibile il controllo dei server (aka cloud)
- con QUIC e WebAssembly vogliono sottrarre autonomia ai client,
 decidendo di volta in volta cosa ciascun utente deve eseguire

Controllando (e personalizzando!!!) il software che eseguiamo, i
contenuti che consumiamo e le nostre comunicazioni...

...potranno assicurarci un futuro radioso di pace (romana) e prosperità.


Un walled garden... da cui nessuno vorrà più uscire. :-D [2]


Giacomo

1) Non serve un nuovo protocollo per questo, come non servivano le
  Server Push in HTTP/2: basterebbe un nuovo mime type che, alla
  richiesta di una risorsa, trasferisse un archivio contenente tutti i
  file necessari al rendering in una gerarchia analoga a quella del
  sito.

2) Per quanto sia evidente, chiariamolo: NON è un complotto. ;-)


------------------------------

Subject: Digest Footer

_______________________________________________
nexa mailing list
nexa@server-nexa.polito.it
https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa


------------------------------

End of nexa Digest, Vol 137, Issue 27
*************************************