[afnog] Network termination point

[sm+afrinic at elandsys.com]

Hi Jaco, Jordi,
At 12:01 AM 09-07-2026, Jaco Kroon wrote:
>I'm assuming you're referring to the speed commentary?

Yes.

>There are a few assumptions that I make with a high degree of certainty.
>
>1.  FNO will hand off to the C(P)E using a 1Gbps *ethernet* port.
>2.  FNO will shape/police to the relevant speed 
>at L3 on the egress 1Gbps port to the customer.
>2.1.  Specifically for 1Gbps services, this will 
>effectively become an L1 measured service - 
>which is the values I calculated; else
>2.2.  For <1Gbps services, the effect, due to 
>being able to ignore L1+L2 overheads, will be less pronounced but still there.
>3.  Customers will fire up speedtest (typically 
>Ookla) and use the download and upload speed 
>values as a measure of how good a specific service performs.
>
>The point I was trying to make isn't that 
>IPv4 >>> IPv6, I *firmly* believe IPv6 is the 
>way to go and that actual performance that 
>matters in pretty much every possible imaginable 
>scenario should be better.  My point is that *consumers* don't see it this

I view IP[insert number] as an address.  The way 
to go depends on how it works for me.  It may be 
different for you as we don't, for example, use the same network operator.

>  way, and the only metric that matters, and on 
> which FNO+ISP get measured by *consumers* is 
> raw speed as measured by tools such as Ookla 
> Speedtest - which invariably will ignore 
> overheads and at best count full L7 
> throughput.  My calculation didn't even 
> consider L5 (TLS) overheads, which fortunately 
> is less since typically a speedtest will pack 
> 16KB at a time here, with a tiny header (IIRC 
> about 5 bytes header, 16-24 byte HMAC, and 
> between 1 and 16 bytes tail padding (Google 
> says between 21 and 40 bytes), even working on 
> the higher value we're talking <0.25% overhead on this layer.

The above would be how it works in ideal conditions.

>This mis-metric in my opinion is also a large 
>reason as to why we suffer so greatly from 
>problems such as buffer bloat.  Because if raw 
>throughput is what you get measured on you want 
>to make sure you keep that link capacity maxed 
>out.  The simplest way to achieve that is to make the buffers larger.

The customer/consumer does not even know about the above.

>The point I'm trying to make towards Jordi is 
>that you cannot punish network operators for 
>shitty end-customer behaviour, which is exactly 
>what his policy proposal will do.  If the 
>measurement changes to something more sensible, 
>I'll be the first to support his proposal, but 
>raw percentage of traffic must be IPv6 is a 
>shitty measure.  I have proposed alternatives.  No response.

I have not even read what the proposal was trying 
to do.  I just saw an email from Jordi.  I'll comment below.

At 12:45 AM 09-07-2026, jordi.palet at consulintel.es wrote:
>Exactly. Working with customers in many EU 
>countries, the reality is that many operators 
>try to avoid you enter into the CPE, but if you 
>ask them, they are enforced to provide the PWD. 
>All the EU countries have a regulator figure 
>that accepts "quick" complains from the users 
>and they act really fast on that. Just telling 
>the operator if you don't give me full access I 
>will place a complain to the regulator,  it 
>works. Of course many people don't know that, 
>but that's a different history, because google will tell you quickly.

Here's what I found (in German): 
https://fsfe.org/news/2025/news-20250124-01.de.html 
That worked because there is actually a group of 
people who will not give up easily.

The regulations are not the same in every 
country.  I doubt that there is a regulation 
similar to the one in the European Union over 
here.  There isn't anything similar to the FSFE over here.

>Usually regulators understand that the ONT is 
>still part of the operator network. So if they 
>provide you an integrated CPE with ONT, you must use either:
>1) A certified ONT (for example in Spain 
>Movistar/Telefonica has 8 certified models for 
>up to 1 Gbps symmetric GPON, which you can buy 
>by less than 10-15 Euros), and then you place whatever CPE you want behind it.
>2) A certified router with ONT. In this case you 
>have much less models to choose.

There isn't any choice of certified ONT over here.

>Regarding the IPv6 paths and Happy Eyeballs 
>(HE), if you read the relevant RFC8305 (v2, v1 
>was 6555), you will see that the first timer is 
>only 50ms. If the resolution of AAAA is slower 
>than the A one. You already have a fallback. 
>This is what could create already lower % of 
>IPv6 traffic than expected. Of course, then you 
>have the other timer, which adds on top of that. 
>Vendors can adapt those timers to their own 
>needs, typically based on telemetry data that collect from users.

I looked up the RFC before I sent this comment: 
https://mailarchive.ietf.org/arch/msg/v6ops/KseRpIh2LqJoNxlo8rq977nLKug

The user will turn off the IPv6 stuff when it is 
the suggested solution to the "speed" problem.

>In fact, Apple tested this HE implementation 
>during 2 years with real users around the world 
>before proposing it in IETF, and from those 
>measurements they gathered the initial suggested timings.

The "real users around the world" is 
imprecise.  As an example, Jaco probably does not 
reside near me.  His measurements would give him 
a better view than, for example, Apple.

>One of the problems with HE is that many 
>operators, unfortunately, don't pay the same 
>attention and monitoring to IPv6 than IPv4. So 
>if there are too many fallbacks to IPv4, you 
>could know it. Also HE itself doesn't have a 
>"reporting" mechanism. I've proposed it for 
>years in IETF, but didn't gained sufficient consensus.

If I may, it's not really the task of the 
operator to track the number of IPv6 connection 
items which failed.  I would defer to the 
operators as I don't operate their networks.

>In any case, this situation is going to change a 
>bit, becase now we have more problem, such as 
>the fallback from QUIC to TCP, etc. If you take 
>a look at the chapter and document of this WG, 
>which is progressing quickly, now the reporting 
>should be an integral part of the protocol:

I don't usually enable data collection.  I doubt 
that is the position of the users over here; it's 
their choice to make. The last presentation I 
watched about QUIC (it was several years ago) 
explained that what the documented 
assumptions/mechanisms did not match how things worked in the real world.

Regards,
S. Moonesamy