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?