<html aria-label="message body"><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">Responding below in-line just a couple of points.<div><br id="lineBreakAtBeginningOfMessage"><div>
<div>Saludos,<br>Jordi<br><br>@jordipalet<br></div>
</div>
<div><br><blockquote type="cite"><div>El 9 jul 2026, a las 12:32, sm+afrinic@elandsys.com escribió:</div><br class="Apple-interchange-newline"><div><div>Hi Jaco, Jordi,<br>At 12:01 AM 09-07-2026, Jaco Kroon wrote:<br><blockquote type="cite">I'm assuming you're referring to the speed commentary?<br></blockquote><br>Yes.<br><br><blockquote type="cite">There are a few assumptions that I make with a high degree of certainty.<br><br>1. FNO will hand off to the C(P)E using a 1Gbps *ethernet* port.<br>2. FNO will shape/police to the relevant speed at L3 on the egress 1Gbps port to the customer.<br>2.1. Specifically for 1Gbps services, this will effectively become an L1 measured service - which is the values I calculated; else<br>2.2. For <1Gbps services, the effect, due to being able to ignore L1+L2 overheads, will be less pronounced but still there.<br>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.<br><br>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<br></blockquote><br>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.<br><br><blockquote type="cite"> 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.<br></blockquote><br>The above would be how it works in ideal conditions.<br><br><blockquote type="cite">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.<br></blockquote><br>The customer/consumer does not even know about the above.<br><br><blockquote type="cite">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.<br></blockquote><br>I have not even read what the proposal was trying to do. I just saw an email from Jordi. I'll comment below.<br><br>At 12:45 AM 09-07-2026, jordi.palet@consulintel.es wrote:<br><blockquote type="cite">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.<br></blockquote><br>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.<br><br>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.<br></div></div></blockquote><div><br></div><div>Even better if you don’t have a regulator asking to enforce that, because it may mean it is already allowed without an enforcement.</div><div><br></div><div>I’ve worked in a few projects in different countries in Africa, and there was not in any of them an enforcement to use the operator provided equipment, but just a few doesn’t provide a good average.</div><br><blockquote type="cite"><div><div><br><blockquote type="cite">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:<br>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.<br>2) A certified router with ONT. In this case you have much less models to choose.<br></blockquote><br>There isn't any choice of certified ONT over here.<br></div></div></blockquote><div><br></div><div>It basically depends on what OLT you have. There are standards, but some vendors do weird things that disallow some other vendors of ONTs being used “correctly”. This may imply that the TDMA slots among the ONT in the passive fiber network (so shared by multiple ONTs), aren’t properly “sequenced” so a badly behaving ONT can impact the speed of other users and it is difficult to diagnose. So basically the OLT may “block” ONTs that aren’t identified as “certified”.</div><br><blockquote type="cite"><div><div><br><blockquote type="cite">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.<br></blockquote><br>I looked up the RFC before I sent this comment: https://mailarchive.ietf.org/arch/msg/v6ops/KseRpIh2LqJoNxlo8rq977nLKug<br><br>The user will turn off the IPv6 stuff when it is the suggested solution to the "speed" problem.<br></div></div></blockquote><div><br></div><div>And this has been done by some gaming companies, because their games have bugs. A terrible thing to do. Who suggests that IPv6 should be disabled because there is a bug, even not related to IPv6, but only visible when you enable IPv6, should be in jail. The right thing to do is to fix your bug.</div><br><blockquote type="cite"><div><div><br><blockquote type="cite">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.<br></blockquote><br>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.<br></div></div></blockquote><div><br></div><div>Sorry, I should have said worldwide. They tested in every iOS user in the world using telemetry tools.</div><br><blockquote type="cite"><div><div><br><blockquote type="cite">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.<br></blockquote><br>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.<br></div></div></blockquote><div><br></div><div>Nooo, this is terrible. All the operators, if they really care about providing a good service, should be doing all kind of measurements and monitoring. It is a must for any operator, otherwise, don’t call yourself an operator!</div><br><blockquote type="cite"><div><div><br><blockquote type="cite">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:<br></blockquote><br>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.<br></div></div></blockquote><div><br></div><div>QUIC is already over 50%.</div><div><br></div><div>https://w3techs.com/technologies/details/ce-http3</div><div><br></div><div>https://www.cellstream.com/2025/02/14/an-update-on-quic-adoption-and-traffic-levels/</div><div><br></div><div><a href="https://blog.apnic.net/2025/06/17/a-quic-progress-report/">https://blog.apnic.net/2025/06/17/a-quic-progress-report/</a><br></div><div></div><div><br></div><div>This is very easy to understand, as is similar to what happens with IPv6.</div><div><br></div><div>If the top-25 destinations (even just 5-10 top) such as Meta, Google, and few CDNs, deploy a protocol and uses OSs (and networks) are able to use it, then the operator traffic for that operator will jump from 0 to 70-75% overnight, as those content providers are the ones offering the 70-75% (or even more) contents in Internet.</div><div><br></div><div>The advantage of QUIC compared with IPv6, is that the operator doesn’t need to do anything in their network.</div><br><blockquote type="cite"><div><div><br>Regards,<br>S. Moonesamy <br></div></div></blockquote></div><br></div><br>**********************************************<br>
IPv4 is over<br>
Are you ready for the new Internet ?<br>
http://www.theipv6company.com<br>
The IPv6 Company<br>
<br>
This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.<br>
<br>
</body></html>