Fibre link bandwidth to FTTC

Hi,

Does anyone here know what the maximum fibre link capacity/bandwidth Openreach would install to a full FTTC cabinet?

I currently live in an area that has one large PCP and two FTTC cabinets, one smaller than the other, along with a g.fast pod on the side of the PCP. So I'm pretty sure at least the oldest cabinet is at full capacity and that's the one I'm on.

The cabinet type is Huawei MA5603T 288 connections, it could be the 384HD type but I haven't had a closer look.

Basically what I'm trying to find out is how Openreach scale the fibre bandwidth from the exchange to the cabinet, is it still only 1gb links and is that per line card or for the whole cabinet and 288 connections?

At peak times I get what I think is Openreaches's best effort when it comes to throughput, and after multiple ISP engineers and exchange checks the congestion/contention can't be coming from anywhere else.

Does anyone know if there is any kind of process where I can get moved onto a different line card inside the cabinet? Or even better, get Openreach to increase to 10gb DSLAM connections.

Thanks

FTTC cabinets use 1Gb/s links or multiples in a LAG group , so 2 links would be 2Gb/s across the whole cabinet.
G.fast t cabinets get 10Gb links.

Edited by witchunt (Sat 29-Aug-20 18:39:08)

Thanks, I get terrible peak time throughput. Had BT come out and check everything. They checked utilization rate of SVLAN. All came back ok. Utilization rate was 23%. They now have another level of team looking into it. I'm guessing it's actually the full to capacity Openreach FTTC cabinet though. Even with a 6gb link, 288 connections on a Friday night all using IPTV etc would soon saturate it enough for the DSLAM to drop my poor TCP packets. I expect it costs some to swap to 10gb, maybe even an upgraded DSLAM and given Covid, they probably don't want to jump the gun.

I'm guessing it's why BT Wholeale give business customers a guarenteed 20mb throughput rate on some plans. 6gbits (6000)% 288 is 20.8mbits guarenteed per business user. Funny enough that's the exact speed I get at peak times 8pm-10pm. Think I must be on a very busy line card or something. At one point it was really really bad and the BT speed tester took an age to run and finally output 19.99mb.

I just hope Openreach upgrade to 10gb links or something, not even sure if BT can ask them to do anything. All they can offer me is to leave me contract, but I actually got a decent price with them. BT also seem to be taking the new Ofcom rules more seriously. Their plans come with Halo 1 now and on the mobile app it does a throughput test from their node somewhere to the hub itself and then also to the device, to rule it out. If the throughput speed is less than the minimum the advertised they automatically open a fault.

Just found this: https://aastatus.net/search.cgi?search=CAPACITY&orde...

Looks like BT are upgrading areas from 1g to 10g. Not sure if that means cabinet or exchange though, but lots going on the last month or so. https://aastatus.net/36331

I doubt they support 10Gb links,at least not without a major hardware upgrade . Some of these DSLAMs have been out there 10 years now and that's a long time in IT .

Think they maybe cablelinks.

Do you have any neighbours with an FTTC service on the same cabinet that you can ask?

That sounds like the only way to determine if the issue is an ISP.

Well I was on TalkTalk and actually moved to BT because of the issue. Haven't spoke to neighbours yet though, but pretty sure it's not an ISP issue. I think the houses built around here are about 12 years old, so not sure when the first FTTC cab was put in.

Edited by deleted (Sun 30-Aug-20 04:05:17)

I did a WinMTR test earlier when it was really bad and found that the packloss started at a private IP address, that after Googling, seems to be either the DSLAM or the Edge router. It's the address for whatever creates the public IP address for my broadband. From then on the latency goes up really bad, like it's bufferbloat or something.

Edited by deleted (Sun 30-Aug-20 04:16:28)

In reply to a post by scott88c:

I did a WinMTR test earlier when it was really bad and found that the packloss started at a private IP address, that after Googling, seems to be either the DSLAM or the Edge router. It's the address for whatever creates the public IP address for my broadband. From then on the latency goes up really bad, like it's bufferbloat or something.

All your traffic is in a PPPoE tunnel to the ISP, you will not see the Openreach infrastructure from your router until the PPP is opened at the ISP, could be hundreds of miles away.

Using WinMTR is confusing, if you see packet loss at a node, but 0% at the end point, it is not packet loss. The node is just ignoring you as it focuses on its real job.

Edited by jchamier (Sun 30-Aug-20 11:22:34)

Yeah I know what you mean about the MTR and some routers just rejecting them. But this is a private IP 172.16.10.180, it's after my router IP and in the hub admin it says the IP is what sets the WAN IP at sync and I thought that the DLM is what does that. I also found this page on the DSLAM https://support.huawei.com/enterprise/en/knowledge/E... and it lists an IP in that private range. If you search Google for "172.16 dslam" it comes up with lots of results using that IP range for DSLAMS.

I did two MTR tests, one just to the router, to check that was ok and then one to bbc. This was the result:
https://imgur.com/a/eQKt0f5

Although the packet loss is low at 1%, it increased the latency big time from that IP and I think it's from the DSLAM buffer or something maybe?

Nope, you’re mixing the TCP/IP layer and the physical DSL layer. The IP address is NOT provided by the DSL dynamic line management or the DSLAM.

The private IP only means it is not internet facing, but it is the device that your PPPoE session is terminating on, and it is giving your router the public IP that it needs to communicate (this is handled by the PPP protocol).

This is exactly how dial up internet worked, as it is an identical PPP process, just over an Ethernet connection instead of a making noises over an analogue modem.

Ah ok thank you. What to you make of the MTR screenshots? BT are claiming no congestion at exchange, so I guess if they checked their equipment, then it could still be the DSLAM dropping packets, as it just wouldn't show in the hop?

If the DSLAM dropped packets you would be disconnected and see that in your router logs.

The 1 missed packet to the BBC is probably whilst the route was establishing. Ignore it.

You have no packet loss. The other lines are routers that are chosing not to reply to you, but get on with the real job.

I don't think that's right at all. The FTTC cabinets are on a shared link it's not a 1-1 service, so even if congestion was really bad, packet loss will happen, once the buffer is full.. It would cause a re-transmission and reduce the TCP throughput to a stable level to prevent collapse, it wouldn't cause a disconnection. And even if it managed to eventually leave the buffer, the latency would of already told the router to throttle the TCP throughput due to such a slow reply. It's the router that will see it as a lost packet and re-transmit and reduce throughput, no need to drop the connection. Openreach do also silently discard certain UDP packets at the DSLAM, which I assume is to avoid congestive collapse.

It's 1% packet loss also in the MTR, not 1 packet. It is seeing it as 1% due to the latency of that hop and further on. The packets do eventually get there, the majority of them, but because of the the latency at the time, it reports it as a lost packet. The reply would eventually go back, but by that time it's already reduced throughput speed. The point is, the router reduces the throughput through the TCP protocol because of this.. How ever would I get bad peak time speeds, except for high latency and reported packet loss?

We know that BT does not throttle speeds. TCP congestion control can though if it does not get a reply in time and this is obviously happening.

Speeds tonight:

https://imgur.com/a/5DyhNJj

This happens every single night, no matter if I turn off the WiFI, change device, keep only one device connected etc,

Typical 8-10pm congestion periods.

Are you saying that BT are throttling throughput speeds against the law? Because if not, then the only other way throughput would slow at peak times is through congestion control and that is caused by packet loss, that in turn is caused by high latency.

In reply to a post by scott88c:

I don't think that's right at all. The FTTC cabinets are on a shared link it's not a 1-1 service, so even if congestion was really bad, packet loss will happen, once the buffer is full.. It would cause a re-transmission and reduce the TCP throughput to a stable level to prevent collapse, it wouldn't cause a disconnection. And even if it managed to eventually leave the buffer, the latency would of already told the router to throttle the TCP throughput due to such a slow reply. It's the router that will see it as a lost packet and re-transmit and reduce throughput, no need to drop the connection. Openreach do also silently discard certain UDP packets at the DSLAM, which I assume is to avoid congestive collapse.

Are you sure they can tell what us UDP is what is TCP at the DSLAM??? No, they see PPPoE packets, which are all PPP, until the handover device.

I suspect the congestion you are getting is not at the cabinet/DSLAM, but further into the network. At the other end of the fibre links, there will be some Openreach equipment connecting to the wholesale carrier (as you're with BT as an ISP, probably BT wholesale). It is quite possible there is a a fault here and insufficient capacity.

How ever would I get bad peak time speeds, except for high latency and reported packet loss?

I agree there is a fault. I am disagreeing with your diagnostic on what is causing the fault.

We know that BT does not throttle speeds. TCP congestion control can though if it does not get a reply in time and this is obviously happening.

As can a fault, as you've said if there is more traffic than backhaul capacity. However you think this is happening at the cabinet/DSLAM, whereas I think this is likely happening further into the network.

Are you saying that BT are throttling throughput speeds against the law? Because if not, then the only other way throughput would slow at peak times is through congestion control and that is caused by packet loss, that in turn is caused by high latency.

No, throttling wouldn't be worth the pain to a company with 4.5 million broadband customers.

I'm not sure there is a law on speed. All home broadband services is sold on a ratio, and with a fault there may be more usage than capacity, so, like the M25 in busy times, everyone has to go slower.

You seem to be applying TCP/IP logic to a network that is tunnelling TCP within Ethernet frames, so what you are expecting to see is hidden. Openreach (and maybe the wholesale customer) can do diagnostic outside the tunnel. Even Virgin Media you cannot see the coax cabinets or fibre points, as the TCP/IP traffic is carried across the DOCSIS until you reach the head-end.

I obviously can't help you, maybe one of the network experienced types will follow up.

Edited by jchamier (Mon 31-Aug-20 10:05:29)

The 172..16.10.180 address is at the ISP. (Used to be BRAS but not all ISPs use them now).

This is why the latency is high for this leg as it is a significant distance from you.

You have an CVLAN from your router to here via the DSLAM ( where it is encapsulated into a SVLAN ) that is routed via the Edge router, Core router etc to your ISP. In BT Retails case via Wholesale equipment that is giving you your public IP address from the box with the private IP address 172.16.10.180. (This iP can be reused within a multiple number of private networks just like your home 192.168.xxx.xxx range).

BT are looking at the SVLAN from your DSLAM to their termination point and giving you the 23% utilisation within that dedicated bandwidth..

From your other screen shots your upstream is close to full (9.2Mb on a 10Mb capacity) . this may be causing your issue. If you have a device that is saturating your upstream it will slow your downstream down as acks will take longer to arrive at the distant end. the 15% loss at your home router may also be a symptom of this. Find the device that is constantly uploading and 'restrain it' and your problem may disappear.

The upload and downoad tests are not done simultaneously, it does the download first and then the upload after. I also get bad results using the BT tester itself, that tests throughput to the hub itself. The latency to that IP is fine at off-peak times. I'm 100% sure no other device or the device itself doing the tests is taking up bandwidth. I've done different devices, the BT hub smart hub 2 throughput test itself etc (The BT app does a throughput test to the hub and then to the device), you can turn everything else off if you want to double check)

So the SVLAN is not located at the exchange? That's not what I heard, or maybe I'm not understanding. Or is the SVLAN after the edge router, in which case, is it possible that could be the issue?

So it could still be an issue of the fibre cable link from the cabinet to the exchange?

I only have one device connected and can monitor the upload/download at the time of tests, so I know for sure nothing is saturating the upload during the peak time tests.

I have also done download only tests, with the same result, with one device connected.

If BT are saying the SVLAN is congested free and the problem is not me, where else could be issues? Would it be svlan - edge router - dslam - me or edge router - svlan/dslam - me?

The MTR tests were done with the other tests paused and no other activity.

MTR at off-peak:

https://imgur.com/a/1Te4dH2

Still shows 15% at router but it's just not responding I think, the actual packets are getting to the final hop without higher latency.

Edited by deleted (Mon 31-Aug-20 17:06:53)

I apologise if this has already been covered but you are hardwired rather than using wireless for these various tests, right?

In reply to a post by CarlTSpeak:

I apologise if this has already been covered but you are hardwired rather than using wireless for these various tests, right?

...and this proviso would specifically EXCLUDE any hardwiring using power-line adapters anywhere in the food chain of devices

I emailed someone high up at Openreach a couple of weeks ago. They seemed really on the ball and promised to look into it. I just got a reply from a senior manager on network health.I removed any confidential info.

"Good morning. "Name" has asked me to respond to you regarding the issue you have raised and detailed below.

Our Network Operations Team have been monitoring the DSLAM backhaul link and have confirmed they are seeing capacity issues at certain times which could be causing the speed degradation you have described.

They have a plan in place to provide further capacity to this DSLAM which involves an additional network fibre and the installation of some exchange hardware. They have provided a provisional completion date for these works as the end of September.

Whilst I understand that the problem may continue until this work has been completed; please be assured that I will personally monitor the progress and will inform you of any changes to the completion date."

Please feel free to contact me directly should you have any comments or concerns."

Great support from Openreach. Shame BT couldn't spot the issue though. Just glad it's been found and is getting fixed.

In reply to a post by scott88c:

I emailed someone high up at Openreach a couple of weeks ago. They seemed really on the ball and promised to look into it. I just got a reply from a senior manager on network health.I removed any confidential info.

"Good morning. "Name" has asked me to respond to you regarding the issue you have raised and detailed below.

Our Network Operations Team have been monitoring the DSLAM backhaul link and have confirmed they are seeing capacity issues at certain times which could be causing the speed degradation you have described.

They have a plan in place to provide further capacity to this DSLAM which involves an additional network fibre and the installation of some exchange hardware. They have provided a provisional completion date for these works as the end of September.

Whilst I understand that the problem may continue until this work has been completed; please be assured that I will personally monitor the progress and will inform you of any changes to the completion date."

Please feel free to contact me directly should you have any comments or concerns."

Great support from Openreach. Shame BT couldn't spot the issue though. Just glad it's been found and is getting fixed.

Anytime I've needed to contact Openreach they have been on the ball. 12 months ago my street wasn't FTTC enabled, despite being connected to an Exchange where it was enabled. I wrote an email to the CEO and he got his team to look at the feasibility of it, all it needed was a cabinet change and 3 months later we got it enabled.

They are criticised for many things, but I've found them to be quite helpful over the years (living at different properties).