Seamless Rate Adaptation

Does anyone know if BT are employing any form of SRA on their FTTC lines?

Reason I ask- since I got FTTC about 18 months ago, I occasionally get events that look like a resync- a brief red spike on the BQM, slight change of BT profile (in either direction), but nothing in the router log and my IPv6 address doesn't change as it does when something causes a full resync (like me knocking the power plug out of the modem ).

It's as though the cabinet equipment can do a partial resync "on the fly", perhaps re-arranging the higher frequency bins without having to re-assign the whole lot from scratch?

I don't even know if that's possible, but it would fit the (admittedly circumstantial) evidence.

CPs should be aware that the mechanism for reporting the downstream and upstream line rates relies on a line re-train causing the CP, or the CPE, to initiate a new PPP session or a new DHCP request. The success of this is down to the CP's choice of timers used around PPP / DHCP handling.

If the PPP/DHCP survives a re-train, then the CP will be unaware of any change in the line rate and will not be able to shape appropriately.
The line re-train time for VDSL2 can be anywhere between 10 and 60 seconds, with typical values in the 20-30 second range.
As DHCP typically uses lease timeouts in the order of days rather than seconds, CPs intending to use DHCP are advised to consider the impact of downstream line rate changes on their service and any strategies they could adopt if they wish to shape downstream traffic.

As I read it that could cause what you are describing. The re-sync not detected by IDNet kit, so no no change to IP address (are the IPv6 ones dynamic?). Similarly perhaps not being detected by your router.

In reply to a post by RobertoS:

(are the IPv6 ones dynamic?)

Yes, the IPv6 addresses are dynamic though the IPv4 is static.

That could explain it, looking at the size of the BQM spike a retrain time of 10-15 seconds would fit. Though if I initiate a full resync it's normally more like 30 seconds to a minute which the CP equipment detects with no problem at all! Maybe it's quicker if the DSLAM starts it.

Thanks for that.

I can confirm this matter for you.

I first became aware of it quite a few months ago, when discussing my connection's frequent re-syncs with my own ISP.

I had to send a copy of my modem log as proof as they argued that my connection was in fact stable & included a graph of their own logs in my fault ticket.

I quoted the same extract from the document to them & now they are fully aware of the matter, admitting they had no idea of the issue until I mentioned it.

I use dynamically obtained IP Addressing & the only way to update BT's IP Profile records & show the event in my ISP's logs is to initiate a new PPP session by diconnecting & reconnecting the ROUTER.

For my connection these "on the fly" connection re-syncs usually take around only 16 seconds or so.

A full modem reboot (from its GUI) takes a little longer & also initiates a new PPP session & updates BT's IP Profile/BRAS rate accordingly along with being evident in my ISP's logs, as does a full modem power cycling off & on again.

Obviously, unless you happen to see the modem's DSL light flashing the only way to know how often the modem re-syncs "on the fly" is to either record and/or graph an ongoing record of the connection, and/or manually monitor the unlocked modem's in-built event log.

This matter initially caused much confusion when users complained about poor speeds, yet still having a much higher speed IP Profile.


Here's an example of the modem's in-built log.
If I hadn't manually initiated new PPP sessions via the router, my ISP would only have been aware of the one modem reboot & some of the evnts from 7th April which came from an engineer's visit:-

2012-4-15 11:30:1 Notice 104500 DSL activate succeed
2012-4-15 11:29:44 Notice 104500 DSL deactivate

2012-4-15 2:20:43 Notice 104500 DSL activate succeed
2012-4-15 2:20:21 Notice 104500 DSL deactivate

2012-4-14 18:4:41 Notice 104500 DSL activate succeed
2012-4-14 18:4:24 Notice 104500 DSL deactivate

2012-4-13 5:28:35 Notice 104500 DSL activate succeed
2012-4-13 5:28:19 Notice 104500 DSL deactivate

2012-4-12 21:24:11 Notice 104500 DSL activate succeed
2012-4-12 21:23:50 Notice 104500 DSL deactivate

2000-1-1 0:0:21 Notice 104500 DSL activate succeed
2000-1-1 0:0:18 Debug 104500 LAN1 up
2000-1-1 0:0:16 Debug 104500 LAN2 up
2000-1-1 0:0:16 Notice 1 System up
2000-1-1 0:0:3 Warning 10400 KLOB Pool 1 Initialized: 1048576 bytes <0x80300000 ... 0x80400000>
2012-4-12 12:55:53 Warning 104001 System reboot

2012-4-12 10:53:41 Notice 104500 DSL activate succeed
2012-4-12 10:53:14 Notice 104500 DSL deactivate

2012-4-8 22:12:49 Notice 104500 DSL activate succeed
2012-4-8 22:12:33 Notice 104500 DSL deactivate

2012-4-8 6:25:6 Notice 104500 DSL activate succeed
2012-4-8 6:25:6 Critical 10400 Line 0: VDSL2 link up, Path 0, us=5768, ds=31048
2012-4-8 6:24:50 Notice 104500 DSL deactivate

2012-4-7 12:17:7 Notice 104500 DSL activate succeed
2012-4-7 12:13:22 Notice 104500 DSL deactivate

2012-4-7 12:4:36 Notice 104500 DSL activate succeed
2012-4-7 12:4:20 Notice 104500 DSL deactivate

2012-4-7 11:46:50 Notice 104500 DSL activate succeed
2012-4-7 10:23:33 Notice 104500 DSL deactivate

2012-4-7 10:22:45 Notice 104500 DSL activate succeed
2012-4-7 10:21:58 Notice 104500 DSL deactivate

2012-4-7 10:2:7 Notice 104500 DSL activate succeed
2012-4-7 9:54:13 Notice 104500 DSL deactivate


Following a reboot or power cycle, the modem's internal clock has to be reset, but doesn't require resetting following an "on the fly" re-sync.

My connection is much more stable now than it was when I first started reporting its "issues", so just imagine how many re-syncs used to in the modem's log.

And there was me thinking that BT might be trying to sneak into the 21st century... ah well

Thanks.

The success of this is down to the CP's choice of timers used around PPP / DHCP handling.

So what settings are ISPs using on their WAN ports ?

In reply to a post by yarwell:

The success of this is down to the CP's choice of timers used around PPP / DHCP handling.

So what settings are ISPs using on their WAN ports ?

?
[shrug]
How should I know? I'm quite sure you well know from which BT SIN it is a quotation.

you would know by looking at the WAN settings on your router

if its like SRA on adsl then you wont even see a redline, seamless means exactly that, no dropped packets at all.

In reply to a post by Chrysalis:

if its like SRA on adsl then you wont even see a redline, seamless means exactly that, no dropped packets at all.

Not the implementation I experienced. Of course that could just have been BE bad at configuring it but frankly it lived down to my expectations. I don't think anyone on the trial was very impressed.