I've always thought that the TCP protocol was the heart of the ingenuity that is the Internet. TCP is a flow control protocol that strives to produce both fair efficient outcomes, both for each TCP session, but for the networ4k as well. The essential feedback signal used by TCP is congestion-based packet loss, but this isn't the only approach. Another approach lies in enrolling the aassistance of the network's routers, and use packet marking instead of loss to signal to the TCP end hosts that network congestion is taking place. This form of signalling, Explicit Congestion Notification is explored in this article, as well as the outcomes of a measurement exercise to establish just how widely we used this alternativer form of congestion signalling.
I've always thought that the TCP protocol was the heart of the ingenuity that is the Internet. TCP is a flow control protocol that strives to produce both fair efficient outcomes, both for each TCP session, but for the networ4k as well. The essential feedback signal used by TCP is congestion-based packet loss, but this isn't the only approach. Another approach lies in enrolling the aassistance of the network's routers, and use packet marking instead of loss to signal to the TCP end hosts that network congestion is taking place. This form of signalling, Explicit Congestion Notification is explored in this article, as well as the outcomes of a measurement exercise to establish just how widely we used this alternativer form of congestion signalling.
The Internet Engineering Task Force (IETF) meets three times a year to develop Internet Standards and related best practices. At its July 2025 meeting in Madrid, several sessions explored the evolving role of congestion control in transport protocols and sparked the observations in this post.
The Internet Engineering Task Force (IETF) meets three times a year to develop Internet Standards and related best practices. At its July 2025 meeting in Madrid, several sessions explored the evolving role of congestion control in transport protocols and sparked the observations in this post.
As usual, IETF 123 was a busy week for DNS folk. I'll cover the material presented at the DELEG and DNSOP working groups. There is more to the DNS at IETF meetings than just these two working groups, and I'll skip over Adaptive DNS Discovery (ADD), Extensions for Scalable DNS Service Discovery (DNSSD), and DANE Authentication for Network Clients Everywhere (DANCE) in the interests of trying to keep this report (relatively) brief!
As usual, IETF 123 was a busy week for DNS folk. I'll cover the material presented at the DELEG and DNSOP working groups. There is more to the DNS at IETF meetings than just these two working groups, and I'll skip over Adaptive DNS Discovery (ADD), Extensions for Scalable DNS Service Discovery (DNSSD), and DANE Authentication for Network Clients Everywhere (DANCE) in the interests of trying to keep this report (relatively) brief!
he IEPG meeting is held each Sunday at the start of the IETF week. There is no particular theme for these sessions, although subjects of operational relevance are encouraged (www.iepg.org). These are my impressions of the presentations that were made at this IEPG meeting att the start of IETF 123.
The IEPG meeting is held each Sunday at the start of the IETF week. There is no particular theme for these sessions, although subjects of operational relevance are encouraged (www.iepg.org). These are my impressions of the presentations that were made at this IEPG meeting att the start of IETF 123.
We look in detail at the mechanisms used to trigger a client application (typically a browser) to connect to the server using the QUIC transport protocol.
We look in detail at the mechanisms used to trigger a client application (typically a browser) to connect to the server using the QUIC transport protocol.
The Internet was deliberately designed as a simple common substrate packet-switched network that could be able to support a huge variety of digital service profiles. The Internet's service profile was defined in the connecting devices at the edge, and not in the switching equipment in the middle of the network. The network model was intentionally so sparse that it was incapable of becoming ossified! How's that turned out?
The Internet was deliberately designed as a simple common substrate packet-switched network that could be able to support a huge variety of digital service profiles. The Internet's service profile was defined in the connecting devices at the edge, and not in the switching equipment in the middle of the network. The network model was intentionally so sparse that it was incapable of becoming ossified! How's that turned out?
There has been a major change in the landscape of the internet over the past few years with the progressive introduction of the QUIC transport protocol. Here I’d like to look at where we are up to with the deployment of QUIC on the public Internet. In so doing we also need to consider whether the DNS is ossifying in front of our eyes!
There has been a major change in the landscape of the internet over the past few years with the progressive introduction of the QUIC transport protocol. Here I’d like to look at where we are up to with the deployment of QUIC on the public Internet. In so doing we also need to consider whether the DNS is ossifying in front of our eyes!
I want to look at just one day of the operation of the Internet’s BGP network by looking at the behaviour of a single BGP session. Nothing special or extraordinary happened on that day. There were no large-scale power blackouts, no major faults in the world’s submarine cable network, nor in the terrestrial trunk cable systems. No headlining-grabbing cyber attack took place on that day, as far as I’m aware. It was just an ordinary Thursday on the Internet, just like any other day, and I selected this day due to its very ordinariness! WhAt can this day tell us about BGP and the way we use it?
I want to look at just one day of the operation of the Internet’s BGP network by looking at the behaviour of a single BGP session. Nothing special or extraordinary happened on that day. There were no large-scale power blackouts, no major faults in the world’s submarine cable network, nor in the terrestrial trunk cable systems. No headlining-grabbing cyber attack took place on that day, as far as I’m aware. It was just an ordinary Thursday on the Internet, just like any other day, and I selected this day due to its very ordinariness! WhAt can this day tell us about BGP and the way we use it?
I would like to look at the ways in which the operators of the number Resource Public Key Infrastructure (RPKI) have deployed this infrastructure in a way that maximises its available and performance and hardens it against potential service interruptions, or in other words, an examination of the resilience of the RPKI infrastructure.
I would like to look at the ways in which the operators of the number Resource Public Key Infrastructure (RPKI) have deployed this infrastructure in a way that maximises its available and performance and hardens it against potential service interruptions, or in other words, an examination of the resilience of the RPKI infrastructure.
Potaroo blog