Note di Matteo

IP Addresses through 2025 è una mega analisi di Geoff Huston, guru della Internet australiana, sullo stato di allocazione delle risorse IP, sia IPv4 che IPv6.

ttl è un mtr con qualche funzione in più, tra cui enrichment dei dati ASN e DNS:

Key features of ttl include:

• Multi-flow probing – Enumerates all load-balanced paths (no more seeing just one path through ECMP).

• Path MTU discovery – Pinpoints exactly where fragmentation kills your jumbo frames.

• NAT detection – Reveals when a middlebox is quietly rewriting your source ports.

• Route flap alerts – Catches BGP instability as it happens by detecting path changes in real time.

• PeeringDB integration – Identifies which Internet Exchange (IX) you're crossing in your route.

• MPLS label visibility – Exposes provider LSP paths by decoding MPLS labels from ICMP responses.

• Smart loss detection – Distinguishes real packet loss from routers simply rate-limiting ICMP replies.

• Modern TUI – Features live stats, jitter calculation, ASN/GeoIP enrichment, and a sleek terminal UI (no 1990s look-and-feel).

• Scriptable output – JSON and CSV export for automating analysis or proving that yes, the problem is their network.

(LinkedIn)

ping6.it permette di confrontare la latenza IPv4 e IPv6 con i "protocolli" ping, traceroute, mtr, risoluzione DNS, HTTP.

(Antonio Prado)

C'è uno storico problema di TCP che torna periodicamente nelle discussioni online (quella di oggi): il modo in cui l'algoritmo di Nagle e gli ACK ritardati interagiscono causando latenza aggiuntiva non necessaria. Nello specifico:

• L'algoritmo di Nagle ritarda la trasmissione di dati da parte del client finché ci sono dei dati non confermati, con l'idea di ridurre l'overhead dell'header TCP/IP. Ad esempio se scrivo una lettera in un terminale remoto i dati da trasmettere sono pari a 1 byte, ma gli header sono decine di byte.
• Gli ACK ritardati agiscono dall'altro lato della connessione ritardando appunto gli ACK se si ritiene che ci saranno a breve (es. 200ms) dati di risposta da inviare (piggybacking sull'ACK).

Il risultato è questo:

The interaction between these two features causes a problem: Nagle’s algorithm is blocking sending more data until an ACK is received, but delayed ack is delaying that ack until a response is ready.

Da qui la "proposta" di un ingegnere AWS di disattivare Nagle praticamente sempre, e quindi attivare l'opzione TCP_NODELAY sui socket oppure a livello di sistema operativo:

First, the uncontroversial take: if you’re building a latency-sensitive distributed system running on modern datacenter-class hardware, enable TCP_NODELAY (disable Nagle’s algorithm) without worries. You don’t need to feel bad. It’s not a sin. It’s OK. Just go ahead.

More controversially, I suspect that Nagle’s algorithm just isn’t needed on modern systems, given the traffic and application mix, and the capabilities of the hardware we have today. In other words, TCP_NODELAY should be the default.

Ottimizzazioni di un'altra era nell'app Facebook:

In 2012 we took this wild ride at mobile infra at Facebook when trying to reduce the several-seconds long load time for “Newsfeed”. A few people worked on different approaches. Something we quickly realized was that setting up a connection with TCP and TLS was incredibly slow on mobile networks at the time. The fix was to have just one, keep it alive and multiplex. Shaved a whole second off. But it was still slow. Several people were convince that us sending JSON was the problem, so two different teams started to work on compact binary encoding. After a lot of experimentation what actually worked out best was to send JSON with ordered fields and a compile-time generated parser. Turns out both our iOS and Android app would do something silly like: 1) read all JSON data from server into a buffer, 2) decode that buffer with a generic JSON decoder into lists & dicts, 3) traverse those structures and build the final struct/class tree. Oh and another neat thing we eventually did—when the network connection needed to be setup—was to send an optimistic UDP packet to the server saying “get started fetching data for the following query”; once the real connection was established, TLS handshake completed and user session authenticated, the response was already ready to be sent back.

Di recente Google ha cambiato la policy di peering per quanto riguarda Google Cloud e YouTube:

• Niente più nuovi peering negli IXP pubblici.
• PNI min. 100 Gbps su traffico minimo di 10 Gbps di picco (settlement free).
• Per tutto il resto il consiglio è di affidarsi a uno degli ISP "certificati" di questa lista (IP transit a pagamento, presumo), che hanno almeno due interconnessioni in almeno un'area metropolitana di Google.

(video)

Private peering allows a network to connect directly with Google over a dedicated physical link known as a private network interconnect (PNI).

Google offers 100G and 400G private peering (PNI) at the facilities listed in our PeeringDB entry. Note that this type of direct peering occurs at common physical locations, and both Google and any peering network bear their own costs in reaching any such location.

Google no longer accepts new peering requests at internet exchanges (IXPs). However, Google maintains dedicated connectivity to the internet exchanges (IXPs) listed in our PeeringDB entry. We also maintain existing BGP sessions across internet exchanges where we are connected. For networks who do not meet our PNI requirements Google will serve those networks via indirect paths.

(peering.google.com)

AWS Lambda networking over IPv6 is here!

In Francia i provider DNS devono bloccare domini su richiesta anche in assenza di una sentenza (ricorda qualcosa...):

We sought legal advice, and unfortunately discovered that French law, specifically Article 6-I-7 of the Loi pour la Confiance dans l'Économie Numérique (LCEN), might actually require us to respond and apply blocking measures, at least for French users.

That said, this whole situation shows just how inadequate this regulation is. Such decisions should be made by a court — a private company shouldn’t have to decide what counts as “illegal” content under threat of legal action.

(Adguard)

Anche Vodafone DE adotta la strategia del depeering, sulla scia di Deutsche Telekom:

By the end of 2025, Vodafone will have completely withdrawn from every public internet exchange in Germany, including DE-CIX Frankfurt, the largest internet exchange on the planet. Instead, all traffic will flow through a single company called Inter.link, which possibly will charge content providers based on how much data they send to Vodafone customers. It might be the telecom equivalent of a landlord announcing they're demolishing all the sidewalks in town and replacing them with a private toll road.

[...]

Think about that: you pay Vodafone for internet access. YouTube pays Inter.link for the privilege of serving you. Both ends pay, but the service you receive gets worse because the architecture degrades and bottlenecks concentrate through fewer connection points. Vodafone saves money on operational overhead while extracting new revenue from content providers. You, the customer, subsidize this twice and get a degraded product.

[...]

You'll have a two-tiered internet: fast lanes for services that pay, slow lanes for everything else. [...] When you pay Vodafone for internet service, you think you're buying neutral access to the global internet. You're not. You're buying access to Vodafone's network, and Vodafone controls how well that network connects to everything else.

Dall'ottimo articolo di Coffee.link che spiega bene il contesto e il precedente di DT e relativi notevoli effetti sulla qualità di Internet.

Numero di utenti per indirizzo IP nel mondo:

E l'uso di CGNAT, così come rilevato da un algoritmo di Cloudflare:

(Cloudflare)

I talebani hanno "spento Internet" in Afghanistan.

La situazione vista da Cloudflare:

E da DataPacket/CDN77: