Kitz ADSL Broadband Information
adsl spacer  
Support this site
Home Broadband ISPs Tech Routers Wiki Forum
 
     
   Compare ISP   Rate your ISP
   Glossary   Glossary
 
Please login or register.

Login with username, password and session length
Advanced search  

News:

Pages: [1] 2

Author Topic: BT notifications of line speeds  (Read 3895 times)

Weaver

  • Senior Kitizen
  • ******
  • Posts: 11459
  • Retd s/w dev; A&A; 4x7km ADSL2 lines; Firebrick
BT notifications of line speeds
« on: January 09, 2022, 04:50:32 PM »

My ISP, Andrews and Arnold, gets notifications from BT telling them that the downstream (and upstream?) speed of a line has changed. I’m assuming that TalkTalk wholesale does something similar. Does anyone have any idea how this works?

I was wondering about G.Fast. Since that has SRA, for the first time for BT, I wonder if dynamic speed-changed events get sent to the ISP in the same fashion. With pre-SRA DSL, BT sends notification events to the ISP when a PPP link connects (or when a DSL link goes into the ShowTime state) so there has not been a case in the past where dynamic rate changing message have been delivered quickly. Am I correct?
Logged

Reformed

  • Reg Member
  • ***
  • Posts: 318
Re: BT notifications of line speeds
« Reply #1 on: January 09, 2022, 07:56:33 PM »

At connection and, maybe, disconnection only, an AV pair within RADIUS. Connection and disconnection are the only times that BT Wholesale / AN Other would send telemetry unsolicited from the POV of the ISP.

TTB would be doing likewise to allow their ISP customers to properly rate limit connections - ISPs are supposed to shape traffic in the direction of the customer rather than assuming the wholesale operator will do so.

I should mention that SRA is configurable. The owner of the DSLAM configures an SNR margin low and high for SRA to work alongside a hold-down timer that prevents constant adjustment in one direction. They could happily set SRA downshift to kick in at 2 dB no more often than every 60 seconds and upshift at 31 dB no more often than every 16383 seconds - 5 bits each for downshift and upshift margin and 14 bits for timers in each direction in seconds.

Weaver

  • Senior Kitizen
  • ******
  • Posts: 11459
  • Retd s/w dev; A&A; 4x7km ADSL2 lines; Firebrick
Re: BT notifications of line speeds
« Reply #2 on: January 09, 2022, 10:28:52 PM »

So the ISP gets a message from RADIUS (rather than polling it - shudders). I don’t understand how BT or BT wholesale G.Fast ISPs are supposed to do rate limiting in conjunction with SRA.
Logged

Reformed

  • Reg Member
  • ***
  • Posts: 318
Re: BT notifications of line speeds
« Reply #3 on: January 13, 2022, 12:37:04 AM »

The changes aren't reported. The rate limit becomes inaccurate.

https://www.openreach.co.uk/cpportal/content/dam/cpportal/public/images-and-documents/home/help-and-support/sins/documents/SIN_527.pdf

Quote
2.1.6  Shaping

As SRA is active  at the  physical  transmission layer for G.fast,  any  actual rate insertion cannot  be  relied upon by  CP  equipment as the  active  line  rate will vary  without  any notification to CP  equipment.  The  CP  is  therefore  expected to shape, per  end-user service,  the downstream traffic to match the  product rate or  maximum  attainable line rate (whichever is lower)  and use  prioritisation via  802.1p bits (per user)  to  ensure correct scheduling  and prioritisation of  traffic egress to the G.fast  DSLAM  interface.   The  CP  can use  the performance  metrics they  receive from Openreach to update  the traffic shaping.

Operators could use TR-069 or periodically query Openreach to obtain more up to date information.
« Last Edit: January 13, 2022, 12:42:41 AM by Reformed »
Logged

Weaver

  • Senior Kitizen
  • ******
  • Posts: 11459
  • Retd s/w dev; A&A; 4x7km ADSL2 lines; Firebrick
Re: BT notifications of line speeds
« Reply #4 on: January 13, 2022, 03:05:58 AM »

That’s talking about CPE and upstream no?

I was thinking about the ISP’s ingress rate limiting and the downstream. My ISP Andrews and Arnold offers line bonding and splits the traffic fraction correctly according to the line rates of the various lines, and handles the case where lines are out of action (because it can detect that a line is really down by using regular PPP LCP ‘pings’ every n secs), but it needs the accurate line speeds from eg BT to get the traffic fractions correct. A&A doesn’t sell G.Fast though.
Logged

meritez

  • Content Team
  • Kitizen
  • *
  • Posts: 1623
Re: BT notifications of line speeds
« Reply #5 on: January 13, 2022, 10:07:00 AM »

My ISP, Andrews and Arnold, gets notifications from BT telling them that the downstream (and upstream?) speed of a line has changed. I’m assuming that TalkTalk wholesale does something similar. Does anyone have any idea how this works?

I was wondering about G.Fast. Since that has SRA, for the first time for BT, I wonder if dynamic speed-changed events get sent to the ISP in the same fashion. With pre-SRA DSL, BT sends notification events to the ISP when a PPP link connects (or when a DSL link goes into the ShowTime state) so there has not been a case in the past where dynamic rate changing message have been delivered quickly. Am I correct?

Do you only see the notifications on a re-authentication?
Logged

Reformed

  • Reg Member
  • ***
  • Posts: 318
Re: BT notifications of line speeds
« Reply #6 on: January 13, 2022, 11:55:33 AM »

That’s talking about CPE and upstream no?

No. It's talking about CPs shaping downstream. No need for any rate limiting upstream on G.fast, the PHY layer takes care of that.

In your scenario you'd go without perfect balancing for a while. Openreach do not provide real-time updates on SRA to their customers and do not plan to.

Weaver

  • Senior Kitizen
  • ******
  • Posts: 11459
  • Retd s/w dev; A&A; 4x7km ADSL2 lines; Firebrick
Re: BT notifications of line speeds
« Reply #7 on: January 13, 2022, 06:20:08 PM »

> Do you only see the notifications on a re-authentication?

Yes. The notification events are visible to me in AA’s per-line logs and are shown at the same time there’s a DSL retrain, see below, where I manually forced a modem to DSL-reconnect (by commanding it to reboot itself).

Quote
2022-01-13 00:26:02      SMS to Mrs_Weaver: Delivered to handset 2022-01-13 00:25:59   SMS
2022-01-13 00:25:59      Sent KCI email Weaver 2022-01-13 00:25:55 DSL line up (down 2 minutes)   KCI
2022-01-13 00:25:59      Sent KCI sms Mrs_Weaver 2022-01-13 00:25:55 DSL line up (down 2 minutes)   KCI
2022-01-13 00:25:59      Sent KCI tweet Weaver 2022-01-13 00:25:55 DSL line up (down 2 minutes)   KCI
2022-01-13 00:25:58      Tx rate (adjusted) 2655313 to 2541218 (rx 392000)   -Auto-
2022-01-13 00:23:41      SMS to Mrs_Weaver: Delivered to handset 2022-01-13 00:23:38   SMS
2022-01-13 00:23:39      Sent KCI sms Mrs_Weaver 2022-01-13 00:23:32 Line down (LostCarrier)   KCI
2022-01-13 00:23:39      Sent KCI tweet Weaver 2022-01-13 00:23:32 Line down (LostCarrier)   KCI
2022-01-13 00:23:38      Sent KCI email Weaver 2022-01-13 00:23:32 Line down (LostCarrier)   KCI
Logged

Reformed

  • Reg Member
  • ***
  • Posts: 318
Re: BT notifications of line speeds
« Reply #8 on: January 13, 2022, 09:19:07 PM »

Quote
1.2.3 Rate Reporting

Rates will be reported via PPPoE intermediate agent insertion or DHCP option 82 [4].
These will need to be interpreted by the CP in order to allow payload traffic to be
transmitted optimally.

The upstream and downstream G.fast data rate is reported to the CP upon PPP/DHCP
discovery. The data rate states the upper rate at which Ethernet traffic can be
transmitted on the link. This traffic comprises of:

A 4 byte per frame overhead added by Openreach for internal routing
A degree of overhead introduced by G.fast Packet Transfer Mode (PTM) layer
The end-user traffic sent from the CP, or from the end-user

Quote
1.2.1 VDSL2 rates

The upstream and downstream VDSL2 data rate is reported to the CP BRAS/Radius upon
PPP discovery (a similar mechanism exists for DHCP – see Section 2.1.8). The VDSL2
rate states the upper rate at which Ethernet traffic can be transmitted on the link. This traffic
comprises of:

A 4 byte per frame overhead added by Openreach for internal routing,
A degree of overhead introduced by DSL (Packet Transfer Mode layer),
The EU traffic sent from the CP, or from the EU.

Alex Atkin UK

  • Addicted Kitizen
  • *****
  • Posts: 5260
    • Thinkbroadband Quality Monitors
Re: BT notifications of line speeds
« Reply #9 on: January 14, 2022, 01:26:37 AM »

I'm still lost for how G.fast avoids too much traffic reaching the DSLAM and eventually having to be dropped, wasting backhaul capacity.
Logged
Broadband: Zen Full Fibre 900 + Three 5G Routers: pfSense (Intel N100) + Huawei CPE Pro 2 H122-373 WiFi: Zyxel NWA210AX
Switches: Netgear MS510TXUP, Netgear MS510TXPP, Netgear GS110EMX My Broadband History & Ping Monitors

Reformed

  • Reg Member
  • ***
  • Posts: 318
Re: BT notifications of line speeds
« Reply #10 on: January 14, 2022, 08:07:03 AM »

It doesn't  :)

Weaver

  • Senior Kitizen
  • ******
  • Posts: 11459
  • Retd s/w dev; A&A; 4x7km ADSL2 lines; Firebrick
Re: BT notifications of line speeds
« Reply #11 on: January 14, 2022, 08:32:38 AM »

Of course in the case of TCP, TCP will regulate downstream traffic heading towards the DSL link but when traffic spikes above the sustainable rate then that extra traffic will be dropped wastefully but only momentarily.

In the case of bonded SRA links, god knows.
Logged

Reformed

  • Reg Member
  • ***
  • Posts: 318
Re: BT notifications of line speeds
« Reply #12 on: January 14, 2022, 09:29:45 AM »

Openreach specifically mention using 802.1p to mark higher priority traffic.

Traffic gets buffered all the time. Microbursts are a thing and you have to hit congestion point before congestion control kicks in.

As far as bonded lines go the equipment either side should be able to buffer it. When the buffers fill congestion control kicks in, much as it does when a flow is ramping up seeking maximum throughput.

If your latency rises and/or you see packet loss during a high usage period a buffer is filling or full.

The decision was evidently made that the minimal changes SRA may make weren't worth building an entirely separate telemetry stream.

EDIT: Also worth remembering that we don't know the SRA settings Openreach are using. Support for it is required. Having it switched on isn't. When they seek out a 3 dB margin in normal operation there's not a lot of room for SRA, we don't know how often it will react if it can, and there's DLM monitoring too.

It doesn't appear to be a big deal. Very rare that high throughput, congestion-insensitive traffic will flow.

If the bonding cannot tolerate SRA it's going to have fun with congestion on transport / access network in between customer and endpoint.
« Last Edit: January 14, 2022, 09:35:20 AM by Reformed »
Logged

Alex Atkin UK

  • Addicted Kitizen
  • *****
  • Posts: 5260
    • Thinkbroadband Quality Monitors
Re: BT notifications of line speeds
« Reply #13 on: January 14, 2022, 09:48:15 PM »

Yeah I'd assume its a case of they figured they wont have enough customers on the high-end packages to need to worry about it too much.  A much bigger issue if all their 40/10 customers were getting hammered with traffic coming in faster than it can be delivered.

Fortunately FTTP will pretty much solve everything, doubly so given that its transmitted from a point in the network with bigger pipes to begin with.
Logged
Broadband: Zen Full Fibre 900 + Three 5G Routers: pfSense (Intel N100) + Huawei CPE Pro 2 H122-373 WiFi: Zyxel NWA210AX
Switches: Netgear MS510TXUP, Netgear MS510TXPP, Netgear GS110EMX My Broadband History & Ping Monitors

Chrysalis

  • Content Team
  • Addicted Kitizen
  • *
  • Posts: 7382
  • VM Gig1 - AAISP L2TP
Re: BT notifications of line speeds
« Reply #14 on: January 14, 2022, 10:40:17 PM »

My guess would be that rate limiting is done at initial line sync rate, SRA will never bring a speed above that, and if SRA brings it down, a rate limit a bit too high is still better than no rate limit.

If you asked me 5 years ago I would have frowned upon these rate limits and said no need because TCP regulates itself, but my view has now changed, I have seen my own line been ddosed just from downloading a steam game and also more services are moving to UDP to avoid TCP handshakes.
Logged
Pages: [1] 2