There are a couple of holdouts where companies are not doing HW accelerated PPP on hardware that is barely capable of doing it at line rate; Ubiquiti being one obvious example. I'd welcome a DHCP / Ethernet based service as I do use Ubiquiti gear and have put an OPNsense box in front of it to do PPP...

This seems like a moot discussion though; the only companies that have done DHCP based FTTx in the UK are those who have their own equipment in the exchanges - so Sky and TalkTalk retail I believe. All the BTW backhaul based consumer services like AAISP are PPP because that is how that service works; the login details used steer the connection to the target ISPs LNS. BTW would have to make significant change to their network to change this, it's not something an ISP can implement on their own.

In reply to a post by XGS_Is_On:

Think hardware accelerated PPPoE has been in SoCs for a while now, the weaksauce consumer routers ISPs give need it to hit the throughput target. Shouldn't need too much to get to gigabit throughput through software though unless using the software you described which uses a kernel with bad PPP functionality: single core decapsulation only, no multithreading.

Works fine in software but I needed to upgrade from a PC Engines APU2E4 on moving to 1Gig, it would have been fine for the throughput otherwise. Granted in this case the issue is with the software.

It isn't also just FreeBSD based x64 routers that suffer, all routers will max out at a lower throughput when using PPPoE even with acceleration in the SoC. Whether that becomes a problem depends on what speed packages a person can get or upgrades to how and how long they want to keep their kit. In many cases the need for faster network ports means an upgrade, but you have routers coming with 2.5 or 10Gbps ports that can't manage more than 1.5 or 2.0Gbps when using PPPoE (UDM-Pro seems to one example), but will do significantly more otherwise. Also there is a price we are paying for this acceleration in the kit we buy, and I believe most of the world is or are moving away from PPPoE.

A&A do all sorts of techy and niche things, it is their UPS after all, so given its their own kit and their own software they are show casing, I would have thought it was right up their street.

Edit:

BTW would have to make significant change to their network to change this, it's not something an ISP can implement on their own.

Guess that explains it then. Maybe they have the option with CityFibre in the future?

Edited by E300 (Mon 15-Apr-24 08:51:05)

In reply to a post by jimbof:

There are a couple of holdouts where companies are not doing HW accelerated PPP on hardware that is barely capable of doing it at line rate; Ubiquiti being one obvious example. I'd welcome a DHCP / Ethernet based service as I do use Ubiquiti gear and have put an OPNsense box in front of it to do PPP...

This seems like a moot discussion though; the only companies that have done DHCP based FTTx in the UK are those who have their own equipment in the exchanges - so Sky and TalkTalk retail I believe. All the BTW backhaul based consumer services like AAISP are PPP because that is how that service works; the login details used steer the connection to the target ISPs LNS. BTW would have to make significant change to their network to change this, it's not something an ISP can implement on their own.

Your decision to use a vendor selling gateways rather than dedicated routers at your WAN edge with a ton of other stuff sapping the CPU and, hence, throughput. IDS/IDP, managing APs, etc, all takes a toll. Enthusiast kit with big interfaces doesn't guarantee line rate anyways in my experience: believe enabling IDS/IDP really harms throughput too.

A&A also use CityFibre and could use IP directly rather than PPP, however it was more of a forward thinking question on my part. Very aware their primary supplier uses PPP and mentioned that they didn't want to for GEA. At some point it'll go.

No requirement to use PPP to steer traffic to BTW customers: it's not dialup and they know which port on the DSLAM/OLT the connection came in on which is all they need. Map that to the ISP, repackage in different VLANs, EVPN, off it goes.

Edited by XGS_Is_On (Mon 15-Apr-24 10:10:08)

In reply to a post by E300:

Guess that explains it then. Maybe they have the option with CityFibre in the future?

They do, but until BTW start changing it is it worth it because a small subset of users have marginal hardware running single threaded PPP? All expense for zero practical gain. Need more of a business case, especially when your network is engineered around PPP.

My question to them was purely on the basis that one of the first things mentioned as a case to continue using Firebricks was CQM and that relies on PPP, as does their bonding code, so is the plan to overlay PPP even when the supplier networks are all IP. Also are they still all in on CQM despite that, in the FTTP world with wholesale supplier performance much better, there's far less of a need for it to detect issues.

Customers blip you get a bunch of notifications when they lose and reestablish from the wholesale supplier and your own BNG. Usage is easily monitored at the BNG.

In reply to a post by XGS_Is_On:

They do, but until BTW start changing it is it worth it because a small subset of users have marginal hardware running single threaded PPP? All expense for zero practical gain. Need more of a business case, especially when your network is engineered around PPP.

You keep using the argument of cost or small number of users would benefit, but this ignores the whole ethos of A&A and why people pay extra to join them. I'm sure some made the same arguments back in 2002 when they started implementing IPv6, as in why go to the trouble, no one else uses it, limited websites to connect to, who benefits, what is the business case etc. A&A could turn IPv6 off tomorrow and the Internet would still work so it really wasn't necessary, but they went ahead anyway and were one of the first to do it.

A&A do try to do things differently, try to be ahead of the game, cater for the techies, work with industry to push things along, they advertise as being tech nerds themselves. If they've become like any other ISP, doing nothing unless forced to because it costs money with no practical short term gain, don''t cater for the "tech nerds" by offering anything different or innovative, then what is their selling point given the premium for their services and having their capped usage model that no other ISP has these days? Their "we fix any line" and all the monitoring as a selling point is disappearing as fast as FTTP is appearing

As I said, this was something I would have expected to have been right up their street, I understand the arguments against doing it for 99.99% of all other ISPs.

Edited by E300 (Mon 15-Apr-24 10:38:14)

No requirement to use PPP to steer traffic to BTW customers: it's not dialup and they know which port on the DSLAM/OLT the connection came in on which is all they need. Map that to the ISP, repackage in different VLANs, EVPN, off it goes.

When you say "no requirement" - you're talking about a hypothetical network setup BT could deploy, right, not something that is available now but ISPs aren't choosing to use?

BTW /Openreach appear to be doing the bare minimum of anything with the FTTP implementation, and there looks to be no steering in place with the BTW ISPs I've used.

I have had 2 BTW connections at the same property on the same PON, and BTW don't even police that a certain ISP PPPoE login is originating from a certain ONT. I could happily connect to either BTW ISP (in this case, AAISP or Unchained) via either of the ONTs that I had, and the connection ended up at the ISP whose login details you used, with no obvious error if you used the wrong ONT. In the case of AAISP, it totally broke their CQM setup as their CQM setup looks for the incoming ID it is expecting to tie up the data with your account, yet they still allows the PPPoE connection.

In reply to a post by E300:

A&A do try to do things differently, try to be ahead of the game

Enabling IPv6 is being ahead of the game; making their network more complex to support poor quality client routers in limited scenarios is not.

It's not as if anyone is proposing phasing out of PPP. As others have said, PPP has major advantage for broadband delivery: bonding is one, being able to use L2TP for backup connections is another.

Talktalk only did IPoE because they needed multicast for their old TV service. It's not because they want to make a service for techno-nerds. After all, they're *not* deploying IPv6 either.

Talktalk only did IPoE because they needed multicast for their old TV service. It's not because they want to make a service for techno-nerds. After all, they're *not* deploying IPv6 either.

They didn't have to do it that way though, did they? BT retail also have a multicast IPTV offering while using PPPoE for the client. They could have mirrored that setup I believe.

In reply to a post by jimbof:

No requirement to use PPP to steer traffic to BTW customers: it's not dialup and they know which port on the DSLAM/OLT the connection came in on which is all they need. Map that to the ISP, repackage in different VLANs, EVPN, off it goes.

When you say "no requirement" - you're talking about a hypothetical network setup BT could deploy, right, not something that is available now but ISPs aren't choosing to use?

BTW /Openreach appear to be doing the bare minimum of anything with the FTTP implementation, and there looks to be no steering in place with the BTW ISPs I've used.

I have had 2 BTW connections at the same property on the same PON, and BTW don't even police that a certain ISP PPPoE login is originating from a certain ONT. I could happily connect to either BTW ISP (in this case, AAISP or Unchained) via either of the ONTs that I had, and the connection ended up at the ISP whose login details you used, with no obvious error if you used the wrong ONT. In the case of AAISP, it totally broke their CQM setup as their CQM setup looks for the incoming ID it is expecting to tie up the data with your account, yet they still allows the PPPoE connection.

Openreach wouldn't care about the connections they'd just send both to BTW. They are more than capable of putting the connections into different VLANs on the same 4 port kit, though. I've had, briefly, a 4 port ONT sending 2 to BTW and 1 to Zen GEA.

Yes, I was talking about future capabilities, not current. I can't recall exactly what I was responding to so apologies if out of context. My point was there's no need for PPP to achieve what BTW need to.

I get that there's no reason for it to have to work this way - but it's all in BTWs realm, and there's no indication that will ever happen (witness: 20 years of FTTC working this way, using PPPoE). I think the main point is folk are thinking that by having custom kit or being a niche provider AAISP could do something different and offer an alternative configuration with FTTP via BTW , but the overarching point is they can't because PPPoE is the way BTW make it work for everyone.