Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[ejs]

A BT document, STIN 520, was recently published (or at least, it's dated May 2016), available as usual from http://www.btplc.com/sinet/SINs/index.htm

It contains some technical details about the G.fast pilot, probably nothing much new, it mentions two different headline speed pilots, one at up to 330/50 and another at up to 160/30. The document also contains the requirements for the G.fast modems, in the same way as SIN 498 for FTTC specifies the requirements for VDSL2 modems. There's a section about how the G.fast DLM will adjust the retransmission level or target SNR margin as it deems appropriate.

[burakkucat]

Thank you for mentioning the document. More reading material for me. 

[WWWombat]

it mentions two different headline speed pilots, one at up to 330/50 and another at up to 160/30.

I had started wondering whether BT would offer other GEA speed variants, much like they do for FTTP.

[Chrysalis]

Finally after all these years.

Seamless Rate Adaptation (SRA)
Enabled
Fast Rate Adaptation (FRA)
Enabled

Alot of QoS info in the document, seems openreach are expecting some congestion like I predicted.

[ejs]

I thought one of the reasons for the QoS was that due to the Seamless Rate Adaptation, it won't be possible for your ISP to keep an IP Profile figure up to date.

[WWWombat]

I've read through the document, and come up with these notable features:
- Existing access network (unlike trials previously).
- Separate layer 2 switches, no mixing of NGA1 and NGA2.
- Separate cablelinks (fibre pair with either 1000base-LX or 10GBase-LR).
- No FoD2.
- High level architecture shows interconnect at PCP cabinet.
- Peak rates of 330/50 and 160/30. Prioritisation (guaranteed) rates labelled "TBC".
- Using PPPoE (I think BT wanted to move away from this) and DHCP, with speeds reported during PPP/DHCP
- Speed changes using SRA and FRA, but not reported to BRAS/CP
- G.Fast features: VDSL2 compatibility, RF notching, vectoring, retransmission, SRA, FRA (FRA is new, since the 2015 trials)
- Downstream QoS seems to be the same as NGA1 and trial (minus the FoD2 extras)
- Downstream shaping is affected by SRA, so asks CPs to shape towards the "max attainable" speed (unless "product speed" is lower), and use QoS properly. "Suitable buffering" available.
- Upstream QoS seems new
- Mention of "Single Order G.Fast" as a possibility, alongside voice-specific QoS marking.
- DLM wasn't used in the trials. In the pilot, it is used. For poor lines, it will increase the amount of retransmission (as the preferred choice) or increase the target margin. For good lines, it will decrease the target margin (as the preferred choice) or decrease the amount of retransmission - but, by default, retransmission is always present. (A hint of the VDSL2 3dB trials?)
- A mention of line capping by DLM, but only "aligned to product rate". No banding?
- A mention that users/CPs shouldn't interfere with line rates or noise margins
- Engineer install: Requires NTE5C and SSFP. SSFP being re-designed for G.Fast frequencies.
- Self Install is new: Central filters, and distributed microfilters allowed (coping with 120MHz). Cable from filter to modem should be cat5 minimum.
- Modem: some "envisaged future requirements" removed from trial, but still expecting higher power and higher bits/tone.
- Mentions a new profile 106b that should be supported, at pain of materially impacted performance.
- Operation & Maintenance: Openreach require the ability to collect statistics before and after speed testing, as initiated from a central test head.

[Chrysalis]

From what I understand the QoS is there to ensure prioritised rates are met and to allow CP's to mark traffic at different priority levels so they can ensure certain traffic isnt dropped when there is openreach side congestion.  If there is no congestion the QoS does nothing.

(reply to ejs, as above post was whilst I Was typing).

For what its worth I think this is a good thing, it should avoid the type of situations VM has under congestion scenarios which is traffic stalling due to extreme congestion, and things like torrents able to hog all the bandwidth.

There is also a anti abuse mechanism, so e.g. if a CP marks "all" traffic as prioritised to "cheat" the system then packets above the prioritised rate are auto marked as droppable (depriotitised).

To wombat.

I am confused by one thing, one part of the document says the NTE5 will be a modem, but then another part says the modem is part of a device supplied by the CP, which is it? I guessing the latter.

[WWWombat]

I thought one of the reasons for the QoS was that due to the Seamless Rate Adaptation, it won't be possible for your ISP to keep an IP Profile figure up to date.

As far as I can see, the downstream QoS procedures are very similar to NGA1.

SRA gets more of a mention in the shaping - where previous requirements on the CP have been to shape traffic to the "current line speed", they should now shape towards the "maximum attainable" (or product speed).

Obviously this will then move a dependency to the QoS mechanism working well - which in turn requires the CP to actually make use of it.

Any idea which ISPs use QoS marking on the traffic being sent out?

[Chrysalis]

So all this QoS stuff is in FTTC also? I know prioritised rates are but didnt know it was this complex.

Also what is FRA compared to SRA? needs a new page on the kitz wiki.

[WWWombat]

From what I understand the QoS is there to ensure prioritised rates are met and to allow CP's to mark traffic at different priority levels so they can ensure certain traffic isnt dropped when there is openreach side congestion.  If there is no congestion the QoS does nothing.

I agree - and this, of course, makes the "prioritised rate" an important factor. It exists in today's NGA products, but no-one really mentions it in their sales patter. If congestion is going to become more of a feature (a la VM), then the prioritised rate is going to be an important "excuse" for Openreach.

For what its worth I think this is a good thing, it should avoid the type of situations VM has under congestion scenarios which is traffic stalling due to extreme congestion, and things like torrents able to hog all the bandwidth.

There is also a anti abuse mechanism, so e.g. if a CP marks "all" traffic as prioritised to "cheat" the system then packets above the prioritised rate are auto marked as droppable (depriotitised).

I think the mechanism to assure at least some minimum "fair" rate is a good one here, running alongside proper fair queuing mechanisms.

But...

Now that Openreach are taking some of the onus on traffic shaping away from the CP, and keeping it to themselves, I would have thought some detail of the queuing mechanism would be good. Especially with things like bufferbloat becoming more understood.

So all this QoS stuff is in FTTC also? I know prioritised rates are but didnt know it was this complex.

It is almost identical - using the same priority markers of 0-4, the same drop/don't-drop decisions, same check for cheating.

There was a change in the trial, for FoD2, where priorities 5-7 were included, but they've gone again in the pilot. The mention of "single order G.Fast" suggests use of priority 7 for voice.

Upstream QoS is new, but it doesn't really say much.

Also what is FRA compared to SRA? needs a new page on the kitz wiki.

S=Seamless, F=Fast.

I think the Seamless adaptation is to cope with slow, gradual noise changes. Fast adaptation is the emergency response to catastrophic noise impact, aimed at getting *some* speed back ASAP.

[Chrysalis]

There is one comment in the document near the start that they are buffering more data than usual for the trial, it doesn't say tho if this is temporary or not. I hope they do not create a buffer bloat scenario aka VM.

[niemand]

Any idea which ISPs use QoS marking on the traffic being sent out?

Multicast is tagged with 3.

Looks an awful lot like this is to cater to CPs wanting to run multicast and unicast video, with the potential in the future for VoIP via an additional class. With SRA and FRA, dynamic line rates without signalling back to CP, prioritising these becomes more of an 'issue' and there has to be a way for Openreach to honour the CP's QoS as they can no longer unilaterally implement QoS themselves.

With this in mind 'suitable buffering' is wise.

[aesmith]

Couple of odd things strike me.  I'll gloss over their re-writing of the customer's COS to non-standard values, as I know BT has used non standard markings in previous products.  The odd one is their policy of re-writing COS to "promote" some data if there's not enough already flagged as priority.   I've not seen that, normally the service provider just allows lower priority classes to overflow if the priority allocation isn't being used. 

[WWWombat]

Looks an awful lot like this is to cater to CPs wanting to run multicast and unicast video, with the potential in the future for VoIP via an additional class. With SRA and FRA, dynamic line rates without signalling back to CP, prioritising these becomes more of an 'issue' and there has to be a way for Openreach to honour the CP's QoS as they can no longer unilaterally implement QoS themselves.

I can see all of that needing to be done, but it requires co-operation from the ISP. Multi-cast tagging, I guess, doesn't need ISP co-operation - it comes from BT's separate TV infrastructure.

I wondered whether any ISPs were already tagging their portion.

I know Plusnet have traffic prioritisation they use internally, and the effect is visible in the IP header, and can be captured by wireshark in traffic seen at home. However, I don't know if they also use it to tag traffic going into the BTW/Openreach network.

With this in mind 'suitable buffering' is wise.

Just so long as they implement the queuing right, in particular the packet drop mechanism.

[WWWombat]

The odd one is their policy of re-writing COS to "promote" some data if there's not enough already flagged as priority.   I've not seen that, normally the service provider just allows lower priority classes to overflow if the priority allocation isn't being used.

I wonder if it turns out to be a purely "internal" mechanism, as a tool to help "fair queuing" share the capacity evenly between traffic for many lines.