Kitz Forum
Broadband Related => FTTC and FTTP Issues => Topic started by: boost on February 04, 2019, 05:15:20 PM
-
Is it correct to say there is no fundamental/baseline latency improvement in any of these profiles, it's just the affinity to leap to correct/reduce coding errors?
A 'Speed' or perhaps more appropriately, a lethargic profile binding will just wait longer to interfere, yeh?
Or not? :)
-
Not specifically wait longer, but rather have a higher threshold trigger for the number of errors per day, before taking action.
... and conversely needs to see a lower threshold of errors per day before reversing any previous action.
-
Cool.
So for gamers with healthy lines, it doesn't matter whether you're on 'Speed' or 'Standard', first hop latency will always be the same on a per ISP basis.
Just one more thing... (Columbo voice)
I'm guessing MTBR only counts for ISPs that actually use BT RAS? BT, Plusnet and whoever.
Is it a fair assumption that ISPs like Sky will not be using it, so DLM has no way to know if a resync has occurred via a RADIUS check?
So the whole DLM thing then becomes about ES/Errored Seconds, almost exclusively?
What I don't quite understand is how it might differentiate between DS and US? Are we assuming DLM action is directed specifically at each one? Or is action based on some sort of aggregate?
What does this mean for someone like me who appears to have no DS ES (could be masked by the current level of INP/interleaving, I suppose) but quite a few (yet under the MTBE Green threshold for a Standard/Stable NGA profile) US ES?
This is loads of questions, sorry. My line has been solid for so long, I kinda forgot most of the stuff I learned :D
-
No, MTBR is mean time between retrains, which occur at the VDSL2 level between modem and DSLAM.
-
Thanks.
It makes perfect sense to me that DLM would be able to ascertain a retrain had occurred at the port but the Kitz page on this topic says this:
A retrain event is detected by "a RADIUS transaction having occurred" - ie a new authentication event has been recorded on to the BTw network, which is part of the handshake process of synchronisation.
https://kitz.co.uk/adsl/DLM.htm
Perhaps it's not exclusive to RADIUS but it's implied from that page?
-
Perhaps the kitz page is wrong, unclear, or that particular part is more applicable to ADSL. I'll probably be told that whatever it is supposed to mean is completely correct, regardless of whatever it actually says.
I don't think there's anything to do with authentication or RADIUS (as in PPP login/passwords) happening during the G.994.1 handshake stage of DSL connecting.
-
Of course, what you're saying makes complete sense but the way I read is that DLM/RAMBO/WHATEVER is not some chassis/control plane based process but a completely separate system that was probably written from the ground up for BT.
Presumably, at some point even if it's not the case now, someone thought the best way to detect a resync would be to poll the RAS instead of... receiving a trap from the chassis or whatever. I can imagine, at some point in time, this was the best way they could do it.
Is it still the case today, though? If so, some of us can possibly forget all about MTBR as a DLM metric?
-
Think about all the times you can re-connect the PPP while the DSL modem remains continually connected. This doesn't seem to bother the DLM at all.
I can imagine, at some point in time, this was the best way they could do it.
If it were, then the best way was utterly broken.
-
The DLM controls parameters between DSLAM and modem.
Having a system that takes things like PPP (beyond the DSLAM) into account would make for a bad system.
On ADSL ISP's run their own DLM because they have their own DSLAM's.
Alternatively they can use BT Wholesale DSLAM's and the BTW DLM.
On the NGA DLM OpenReach retain full control regardless of ISP.
AFAIK the DLM doesn't even know what goes on beyond the DSLAM. It has no idea nor does it care about things like PPP.
A good example is if I have my modem connected in bridge mode, synced to the DSLAM, with no router connected so no PPP.
DLM can and will still act on my line. It's only interested in the xDSL link.
I'll happily restart my router dozens of times without DLM being aware of it.
-
It's there in black and white, on Kitz's site :P
I'm making the bold assumption that Kitz didn't dream any of this and it came from the horses mouth at some point.
It sounds like we've all made the same assumption up until this point, though?
My memory is hazy but I don't remember seeing any of these 'DLM' style features on the DSL DSLAM I used to work on. The G.SHDSL DSLAM was a little better endowed, though. I think there was maybe an automated way to bring a bond back into SLA but nothing anywhere as sophisticated as the DLM we know and love. That's what helpdesk staff like me are for, I suppose :P
Plus, how does it work across Huawei, ECI and whatever other vendors they use?
I'm sure the boss will be along shortly to correct our assumptions.
-
It's possible that whoever or whatever kitz got it from was incorrect or they didn't understand it properly themselves.
-
It's there in black and white, on Kitz's site :P
confident in what I wrote above.
Plus, how does it work across Huawei, ECI and whatever other vendors they use?
https://kitz.co.uk/adsl/DLM_system.htm#element_manager
I suggest reading the entire DLM section.
-
Thanks for that link, j0hn.
I'm not sure it confirms what you might hope, though?
'Element Manager' - Agent?
'Data Collector' - Syslog?
'DLM' - A glorified log parser on a 15 minute crontab? Written in PERL? :) (Is this why some of us have to wait weeks for what should take 2-3 days? Invocation failure of some sort?)
'RAMBO' - An administrative front end...?
Abstracted nomenclature for an abstracted control plane. Almost completely meaningless, unfortunately. We're all just guessing... aren't we?
-
I'm not sure it confirms what you might hope, though?
Huh? i don't hope anything.
You asked how it worked between DSLAM vendors and I linked you to kitz page that explains it in detail.
The DSLAMs data collector reports its data to an Element Manager using the SNMP protocol.
It includes things like
Line Data
Line Rate - Sync Speed & other bit rate related information
Line Condition - ie Attenuation, SNR Margin, Power.
Fault Finding Info - ie QLN, Hlog
Event Counters
Line Level - ie Initialisations and failed initialisations
xTU Level - Alarm state errors such as LOS, ES, SES, UAS.
Channel Level - Coding violations such as CRC & HEC and corrected blocks (FEC)
Various configuration Parameters
ie Interleaving, INP, Target SNR, SNR Margin, QoS Profiles, Max Line Rate, Min Line Rate.
Those are all xDSL statistics reported by modem/DSLAM, nothing beyond the DSLAM.
I don't really care what you quote me from an article that's years old and that covers huge chunks of the ADSL DLM.
A retrain event is detected by "a RADIUS transaction having occurred" - ie a new authentication event has been recorded on to the BTw network, which is part of the handshake process of synchronisation.
This must be referring to ADSL.
That's not how NGA DLM works.
You asked about NGA profiles, and I'm telling you how the NGA DLM works.
Like I said previously
A good example is if I have my modem connected in bridge mode, synced to the DSLAM, with no router connected so no PPP.
DLM can and will still act on my line. It's only interested in the xDSL link.
I'll happily restart my router dozens of times without DLM being aware of it.
ADSL is unbundled with multiple DSLAM's operated by multiple providers over multiple DLM systems.
Kits DLM page refers to the BT Wholesale DLM and BT Wholesale control their DSLAM's, the DLM, the BRAS/RADIUS etc.
The NGA DLM can't use PPP/Authentication as the NGA DLM controls every ISP on the DSLAM.
OpenReach don't have control over this info from every ISP in the same way BT Wholesale can control the BRAS for their ADSL DSLAM's.
The NGA system just would not work the way you think it does.
-
It is more applicable to ADSL as the information came from BTw documentation (as opposed to Openreach). The DLM system & RAMBO was originally designed by BT Wholesale... and Openreach 'borrowed' a lot of its technology.
The fact that it's in quotes means that's exactly what the document said. It's not a term I would have used - to me resyncs occur at the DSLAM/MSAN.
However I think it's being assumed in this discussion that RADIUS is the ISP RADIUS, whilst BTw also has its own RADIUS servers to authenticate EU's on to their part of the BTw network and set up the L2TP tunnel.
See here (https://kitz.co.uk/adsl/images/l2tpauthentication.gif)
I'll probably be told that whatever it is supposed to mean is completely correct, regardless of whatever it actually says.
OUCH! Don't shoot the messenger.
-
So for gamers with healthy lines, it doesn't matter whether you're on 'Speed' or 'Standard', first hop latency will always be the same on a per ISP basis.
Yes... BUT if your line does get errors then DLM is more likely to intervene if you are on Standard rather than speed. A couple of years ago I was thinking of moving to another ISP, but one of the reasons I didn't is because that ISP uses Standard profile. My line has weird error bursts every morning for a couple of seconds. There's a good chance that I would be permanently interleaved if on Standard profile.
I'm guessing MTBR only counts for ISPs that actually use BT RAS? BT, Plusnet and whoever.
No Openreach NGA uses MBTR too. The logical assumption would be it gets the info from the Element Manager.
What I don't quite understand is how it might differentiate between DS and US? Are we assuming DLM action is directed specifically at each one? Or is action based on some sort of aggregate?
Upstream and Downstream are counted independently. Its possible for DLM to just take action on the downstream OR upstream OR both.
My memory is hazy but I don't remember seeing any of these 'DLM' style features on the DSL DSLAM I used to work on.
I'm not certain, so don't quote me on this, but I don't think the older BTw MSANS collected any where near as much information about the line as what Openreaches' do.
Openreach NGA has specific aggregation element managers in the exchange which collects and controls data from several DSLAMs at various locations.
RAMBO itself is a separate server box and the DLM system it uses was patented by BT for BT wholesale Historically it was located near to the bRAS because it also controlled RAP. It communicated directly to the bRAS and collected data from numerous MSANs in numerous exchanges.
Openreach these days use MSE bRASes which means that most head-end exchanges have their own bRAS.
-
Thank you all for your thoughts :)
-
kitz - does PN use speed or standard?
-
(Replying on Kitz' behalf.) Plusnet use the speed profile.
-
It looks like 'Element Manager' is a term the fibre crew are more familiar with. GPON, etc. So not, necessarily, a completely made up BT term :D
Does GPON provide the backhaul for the cabs? Do we have any specifics on this?
-
PON / AON / whatever :)
-
A silence befell the crowd.
:police:
-
https://forum.kitz.co.uk/index.php/topic,21480.msg388164.html#msg388164
The whole thread is worth a read.