G.FAST on Demand? FTTP2? Product overlap?

Hi,

I've been doing some research into G.FAST and come up with some interesting conclusions. Yes they are a bit off the wall!

G.FAST isn't FTTDP necessarily.

If you're near enough to an existing cabinet you'll likely be able to order G.FAST. Why?

1) Deployment can be done on demand based on orders for 330 G.FAST products - within distance limitations. Cut down demand. But gives a nice return.
2) No civil engineering is required. Civils are bad..
3) Work can be undertaken by third party engineer. Why not an Openreach engineer? They are committed to BDUK for a very very long time.
4) There is room in the existing cab for a G.FAST module. The cab has power it is also compatible with the FTTP2 2.5Gbps/10Gbps G-PON due to the fact it has a C-WDM splitter pre-installed unless it was one of the original 2010 cabs then you are SOL.

So. From research I've done it looks like this is possible.

At 500 you can get 50 Mbps FTTC and 100Mbps G.Fast.
At 400 you can get 63 MBps FTTC and 200Mbps G.Fast.
At 300 you can get 76 Mbps FTTC and 280Mbps G.Fast.
At 200 you can get 80 Mbps FTTC and 300Mbps G.Fast.

In my area 100,000 properties 30-40% would get >200 Mbps. Maybe ish.

Note: The FTTC figures are not exact but based on real data. The G.FAST is a rough guess but also based on real data. I think BT are getting better results due to the quality of the equipment being far better than they had anticipated.

Also BT have said FTTP2 is ready to go and that is a precursor to G.FAST as G.FAST uses 10Gbps FTTP2 backhaul - all that is required is a new line card.

So will FTTP2 follow a similar principle and be available on demand. Will G.FAST FTTDP fit into that same on demand model?

So is this how it might go?

FTTC <600 meters (rolled out 2016/17)
===============
- G.FAST on demand 300Mbps with zero build cost.
- FTTP2 on demand 1Gbps/10Gbps with low build cost. NO 330 OD

FTTC >600 meters (>2018)
===============
- FTTDP on demand 330Mbps with build cost
- FTTP2 on demand 1/10Gbps with build cost

FTTP Area (2015???)
========
- FTTP2 on demand 1Gbps

Actually why bother with FTTP2 OD.... Hmmm.

?? Any ideas?

Regards,

Gareth

Have seen zero indication that G.Fast will be an on demand product.

Around half of cabinet to premises lines are under 400 metre long, which is around the 200 Mbps point
http://www.thinkbroadband.com/news/6824-vdsl2-has-no...

Varied deployments of in cab (or next to), down pavement chambers or on poles or in buildings are all on the product path, and VDSL2 is already being deployed in mini cabs and in buildings in limited numbers.

G.fast hardware will also be capable of VDSL2, so existing FTTrN deployments may see hardware swap outs to give g.fast functionality.

FTTP is the eventual end goal, but no timetable set, a lot will hinge on whether costs and time to install can be shown to be less in summer trials and then the balance between G.fast and FTTP will be worked out.

NOTE: The GPON for FTTP never actually goes to the cabinets, it is fully passive between the exchange and the premise. The need for no power in the street explains why some areas get P versus C now beyond doing a sprinkling of FTTP.

In reply to a post by MrSaffron:

Have seen zero indication that G.Fast will be an on demand product.

Around half of cabinet to premises lines are under 400 metre long, which is around the 200 Mbps point
http://www.thinkbroadband.com/news/6824-vdsl2-has-no...

Varied deployments of in cab (or next to), down pavement chambers or on poles or in buildings are all on the product path, and VDSL2 is already being deployed in mini cabs and in buildings in limited numbers.

G.fast hardware will also be capable of VDSL2, so existing FTTrN deployments may see hardware swap outs to give g.fast functionality.

<SNIP>

NOTE: The GPON for FTTP never actually goes to the cabinets, it is fully passive between the exchange and the premise. The need for no power in the street explains why some areas get P versus C now beyond doing a sprinkling of FTTP.

Very good points.

Yes I've seen no indication of G.FAST OD either.. Just floating the idea out there and seeing if it sinks or not.

Speed distance figures I used are a guess! But based on some real figures. I'm not claiming they're right!

FTTRN gaining G.FAST is a very very good point!

Isn't an FTTC cabinet a GPON endpoint? That was my point.

Regards,

Gareth

from the business ROI point of view, on demand or some kind of pre interest campaign makes sense.

As spending money to deploy pole based boxes, that may never get used seems wasteful, its higher risk than cabinets as cabinets cover much more properties.

Also I think getting people to move from vdsl services to g.fast will be much harder than from adsl to vdsl.

Cabinets cover more properties, but G.fast nodes usually just hand 8 to 16 lines each

No the FTTC is point to point fibre, GPON for any FTTP is fed from the aggregation node, usually in the ground near to a cabinet but needs no power

There will obviously be a demand component to where BT deploy G.fast, but it's not going to be a product deployed as a bespoke build in the manner that FTTPoD / FoD currently is.

Where BT think there will be high demand for ultrafast, or they have a good relationship with a local area that indicates chance of a high uptake they will build first.

Areas with a high proportion of FTTP almost universally on 80Mb or less will be interesting.

There will be another ultrafast option in your area at some point in the future.

OK. Maybe I didn't put my point across very well. It's GPON p2p without the splitter.

What do you mean by FTTP2?

In some of your post, it looks like you mean XGPON. In other parts, it looks like you are talking about FTTPoD mk.II

And where have BT said FTTP2 is ready to go?

The G.fast trial uses 1G L2S handovers in Gosforth. The 10G trial is for FoD2/G.fast (solely in Huntingdon).

It's important to note that, as far I am aware, the G.fast trial does not use or involve existing cabs. The DPUs are strategically placed (which probably explains why the vast majority of trial postcodes have estimated max headline speeds).

Edited by deleted (Tue 08-Sep-15 20:30:22)

In reply to a post by garethr:

G.FAST isn't FTTDP necessarily.

True. FTTdp is a set of technologies for the node that will host G.Fast. It doesn't have to be located at the DP to be called FTTdp.

Back when the G.fast research started, the design aims were indeed to place these nodes at the DP - and all scaling work has been done predicated on this fact.

As one consequence, in particular, the chipsets are sized at 4, 8, 16 homes. Scaled to be exactly right for a DP.

The results from the research and the first batches of chipsets have emboldened BT - who now think they can lead/push the research to be considerably faster (lower noise floor, more bits per tone, more spectrum, non-linear coding, etc), and to increase the range. The increased range means they need hardware designs for more lines than currently exist.

The battle between short-range aficionados and long-range ones can be glimpsed in the recent Sckipio presentation mentioned here, towards the end:
http://forums.thinkbroadband.com/fibre/4417661-gfast...

Seeing the action going on in the research side, I think BT's initial plans for a G.fast rollout will be something of a holding pattern, in terms of range and capacity, because they really want to be deploying G.Fast-2.

If you're near enough to an existing cabinet you'll likely be able to order G.FAST. Why?

All very true. Whatever a G.fast node turns out to look like, it is a no-brainer to deploy a node at the existing cabinet location ... even if you have to carefully vet the lines which qualify to use it.

due to the fact it has a C-WDM splitter pre-installed unless it was one of the original 2010 cabs then you are SOL.

Didn't know that. Are they retro-fittable?

At 500 you can get 50 Mbps FTTC and 100Mbps G.Fast.
At 400 you can get 63 MBps FTTC and 200Mbps G.Fast.
At 300 you can get 76 Mbps FTTC and 280Mbps G.Fast.
At 200 you can get 80 Mbps FTTC and 300Mbps G.Fast.

Those broadly fit with the speeds being quoted by Sckipio (though theirs is a combined total):
http://gfastnews.com/index.php/90-r/157-suddenly-g-f...

I assume your FTTC figures really relate to unvectored capability. With vectoring, you'd likely get 100Mbps to 400m. Even without vectoring, you can get 80Mbps at 400m initially ... but the dreaded crosstalk will eat away at that.

In my area 100,000 properties 30-40% would get >200 Mbps. Maybe ish.

The Sagentia report gives a nice breakdown of line lengths:
http://postimg.org/image/bp372fcnn/

A design target range of 400m would perhaps capture 50% of lines from the existing cabinet sites; A second ring (using 1, 2 or 3 nodes, depending on shape) sited at 400m would capture the next 35% of lines. A third ring at 800m would target the next 10% of lines.

If the design target has to be dropped to 300m, then deployment would need one additional ring of nodes.

BUT...

Should BT be trying to maximise the range (which minimises the cost)? Probably ... if they think there is a future FTTP rollout needed later.

On the other hand, there is reason to think that brownfield sites will keep that last little chunk of copper for good ... so G.fast will be the last upgrade they'll ever get (unless they pay for it themselves). In that case, siting nodes at the DP makes sense.

all that is required is a new line card.

A new linecard where?

In reply to a post by MrSaffron:

G.fast hardware will also be capable of VDSL2, so existing FTTrN deployments may see hardware swap outs to give g.fast functionality.

I have assumed the same, but my recent reading suggests the opposite: that G.fast nodes will not include VDSL2 capability.

In Swisscom's FTTS project, they intend to swap out their VDSL2 hardware with plug-compatible G.fast hardware - all Alcatel-based. If the new nodes have no VDSL2 fallback, then they'd have to be being placed with line lengths that will function with G.fast.

Our FTTRN deployments could be swapped out in a similar way ... depending on the coverage range.

FTTP is the eventual end goal, but no timetable set, a lot will hinge on whether costs and time to install can be shown to be less in summer trials and then the balance between G.fast and FTTP will be worked out.

Certainly that balance of costs will determine whether G.fast ever gets considered. However, I'm no longer convinced that FTTP is assured to be the end-goal everywhere.

I suspect that the tricky brownfield locations (eg direct-buried cable) may well find themselves with G.fast as a final solution.

For areas with direct buried copper then the cost of the final fibre drop may make FTTH goal difficult to justify in a ten year plan even. Add the landlord who is slow to reply to wayleave requests, or even refuses and many small flats will have copper as final drop for a long time.

While those who work from home are happy to be around for an install visit, the work pressures for many make it difficult to have someone at home for all the FTTH/FTTP stuff. Remember the posts from people desperate to get a Saturday install slot for FTTC.

The decades of the UK loving the detached and semi home are coming back to bite us.

In reply to a post by garethr:

Isn't an FTTC cabinet a GPON endpoint? That was my point.

In reply to a post by garethr:

OK. Maybe I didn't put my point across very well. It's GPON p2p without the splitter.

If there is no splitter, it isn't a PON!

An FTTC cabinet uses one or more NGA P2P distribution fibres from the aggregation node ... which will be spliced onto spine fibre at the AN.

The fibre spine, running out from a master exchange head-end, will be a fibre cable with up to 288 fibres, leading to a chain of aggregation nodes. A proportion of the fibres will terminate in the aggregation node, while the rest will loop through to the next aggregation node.

BT will have dimensioned the cable size carefully, so the right number of fibres terminate in a node - obviously ready for both current and future usage.

It seems like BT classify those fibres in 2 ways:
- "P2P BAU", which I assume is Point-to-point Business As Usual.
- "NGA Spine Fibres" which seem to be intended for PON purposes. The only current PON type is GPON, but XGPON will turn up.

The BT installation manual for an Aggregation node suggests that NGA P2P distribution fibres (ie those from the AN to the FTTC cabinets) actually end up spliced to the "P2P BAU" fibres.

BT clearly classify the PON and P2P worlds very differently.

What isn't clear to me yet is whether the G.fast boxes will end up physically connected direct to an NGA P2P spine fibre, or as part of an XGPON, or it will be physically connected into an existing FTTC cabinet.

As far as I can make out, the Alcatel system architecture for their current VDSL2 micro-nodes (and therefore the plug-compatible G.fast micro-nodes) means they are managed as sub-elements of a full-size FTTC node. Such management might require a physical interconnection (though not necessarily) and some architectural diagrams show a connection in this way.

I haven't found any indication about how Huawei expect their small nodes (FTTRN or G.fast) to be connected.

wwwombat well what you just posted concerns me, it seems BT want to push the range ultimately to decrease costs, so they dont have push out fiber as far and deploy less nodes, the increased range I imagine would mean more variability in access speeds, which is bad for the end user. Its a bit like choosing to deploy adsl2 upto 4km instead of upto 1km, they can sell the product at 4km in the latter example but wouldnt work anywhere near the marketed speeds.

e.g. if I ordered g.fast and ended up with something like 150mbit sync speeds I would be pretty angry not just disappointed. I would expect more than a doubling of speed on a newer generation product, its a big reason why g.fast doesnt excite me, distance based speeds are getting old, bring on fttp please, until then I will keep vdsl2.

This is also why I said I think they will have a harder time selling g.fast, as I am somewhat of a broadband geek and I dont see myself ordering g.fast if available unless there was no extra price premium over vdsl2.

Edited by Chrysalis (Tue 08-Sep-15 15:30:24)

But, G.Fast at 150Mb/s is still a big improvement for a lot of FTTC customers. Over 3 times my current speed and for some getting the node just a bit closer could make a big difference.

Personally I'm hoping the new FTTPoD will be sensible and if it is then I will invest (assuming they let me).

I'm unsure where you've researched but I can perhaps answer some other points raised here and elsewhere.

FTTC
Vectoring will be deployed very soon.

Vectoring will be deployed on a very tactical basis to hit local authority targets. There has been no indication from BT that such a deployment will be widespread, or that there will be much of it in the commercial areas. It is extremely wise to not assume vectoring is arriving.

I reckon any G.FAST to the distribution point will actually be a later project

BT's trials they are doing right now are with G.fast to distribution points. The deployment as it stands will use nodes in varying depths in the network.

G.FAST can do a very fast resync - unlike FTTC. However, BT use PPP at higher network layers which is slow.

PPP is not slow. Certainly not compared to xDSL sync times. It carries overheads but reconnecting a PPP session takes a second or two, most of that delay waiting on RADIUS.

That explains why they are working with both ECI and HUAWEI

Given ECI have no G.fast hardware and Openreach are working with Huawei and Alcatel on the G.fast side the idea that Openreach are working with ECI and Huawei to upgrade cabinets to G.fast doesn't seem to be supported.

The ECI DSLAMs would need a not inconsiderable amount of work, not just new line cards, to run G.fast.

The cab has power it is also compatible with the FTTP2 2.5Gbps/10Gbps G-PON due to the fact it has a C-WDM splitter pre-installed unless it was one of the original 2010 cabs then you are SOL.

There's no CWDM splitter in the cabinets as far as I'm aware. They run on point to point Ethernet backhaul over a single fibre from what I gather which each connection running on a dedicated fibre, 1000Base BX-10. A CWDM splitter is not required to run GPON and XGPON on the same fibre. To backhaul the cabinets with XGPON requires new line cards as the existing ones do not support it.

The only things using PON are FTTP, which is why to connect FTTP customers providers have to pay for a connection to an entirely separate OLT, while they have to pay for connectivity to a layer 2 switch in the exchange to access the FTTC customer base.

The new FTTPoD trials are largely about testing new deployment methods. BT already know XGPON works having tested it out in Cornwall.

G.fast is not dependent on any iteration of FTTPoD; delivering 300Mb to a even a fairly substantial group of properties does not require 10Gb, a single symmetrical gigabit backhaul would be fine for most streets.

Edited by deleted (Tue 08-Sep-15 15:39:58)

doesnt a single gigabit per street seem a bit low for when a single user can pull 300mbit/sec? that is VM type contention and we have seen what happens there.

For a street where a single user can pull 300mbit/sec. I would consider 3gbit/sec absolute minimum for backhaul following the rule that one user cannot use more than 10% of capacity.

And how many other installations of FTTB across Europe rely on Gigabit backhaul per building, and why even if you look at South Korean speed tests (done in country) people don't max out all the time.

Once you supply Gigabit and start to use it you suddenly discover that many hosting providers have speed limits below your actual connection speed.

In reply to a post by Chrysalis:

doesnt a single gigabit per street seem a bit low for when a single user can pull 300mbit/sec? that is VM type contention and we have seen what happens there.

For a street where a single user can pull 300mbit/sec. I would consider 3gbit/sec absolute minimum for backhaul following the rule that one user cannot use more than 10% of capacity.

What is the equivalent setup for VM and their shared coax?

IIRC, they currently bond 8 Eurodocsis channels, each capable of 55Mbps - giving a grand total of 440Mbps. That bandwidth is shared over a few hundred homes, but they'll sell packages of 152Mbps.

That means 3 users, out of a few hundred, can saturate the downstream. However, only around 10% of users actually choose to buy the top-speed package. Two-thirds are on 50Mbps or less, which is a lot closer to your suggested rule.

However, with the current generation of G.Fast nodes, you are looking at 1Gbps backhaul shared over only 8-16 users. That leads to a better contention ratio than with VM.

If BT roll this equipment out, I wonder if they'll be offering lower-speed packages too - especially at 40 and 80Mbps levels.

Edited by deleted (Tue 08-Sep-15 18:00:33)

remember the days of datastream?

isp's could have a wicked 2:1 contention ratio and still be poor due to then users able to saturate the shared pipe so easy.

note we talking about gigabit per street rather than per node, a street could have several g.fast boxes.

Edited by Chrysalis (Tue 08-Sep-15 19:06:02)

Data stream behaviour passed me by....

Won't it be hard for one gigabit to support multiple g.fast nodes in a street? It'll either be 1Gbps P2P, or 2.5Gbps shared GPON, or 10 Gbps shared XGPON. There isn't really a 1Gbps option that works in a shared setup.

Perhaps this makes things clearer -

http://i.imgur.com/ExRoSp1.png

yeah I think it will be 2.5gbps, with possible upgrades in busy areas.

When Openreach were commissioning the cab I'm connected to I'm pretty sure there was a bundle of 4 fibres coming into the right hand side of the cab.

In reply to a post by Chrysalis:

doesnt a single gigabit per street seem a bit low for when a single user can pull 300mbit/sec?

Nope. The rule II have historically seen is that a single customer should not be able to use half the maximum bandwidth.

The Datastream issues came from selling 2Mb on 2Mb, perhaps 3Mb, PVCs

Bandwidth usage rises by a fraction of maximum speed increase when a customer is migrating from a fast SFBB service to another service. Usually doubling the speed of the ultrafast increased usage by 30-40%. This increase further drops as the speeds go higher. 300Mb top speed on GigE would be just fine for nodes of these sizes. 16 connections at 300Mb each contends a gonet 4.8:1 and requires 3 people on the node at an one time pulling down data at full speed to leave 100Mb for the other 13, which will probably be fine as it's extremely unlikely for 3 people of 16 to be downloading at 300Mb simultaneously.

Average usage on heavy broadband ISPs is about 1Mbps per customer at peak period. A 16 person node delivers 60Mbps for each customer.

There are ISPs selling 300Mb on 600Mb, 500Mb on 800Mb. This on full cable nodes.

VM selling 300 on 800 is fine as long as the node sizes are appropriate, hundreds passed per node. BT selling 300 on 1Gb to a handful of customer's is fine.

so your example is gigabit per node not per street?

We will wait and see as to what happens as I think heavy users tend to congregate in certain areas such as student areas for example.

In reply to a post by Ignitionnet:

VM selling 300 on 800 is fine as long as the node sizes are appropriate, hundreds passed per node.

That's perfectly reasonable when you look at averages - especially at 1 Mbps per user.

It's still a bit worrying that only 3 users - out of hundreds - can saturate things.

Buy that man a pint!

In reply to a post by WWWombat:

due to the fact it has a C-WDM splitter pre-installed unless it was one of the original 2010 cabs then you are SOL.

Didn't know that. Are they retro-fittable?

<SNIP>

I assume your FTTC figures really relate to unvectored capability. With vectoring, you'd likely get 100Mbps to 400m. Even without vectoring, you can get 80Mbps at 400m initially ... but the dreaded crosstalk will eat away at that.

In my area 100,000 properties 30-40% would get >200 Mbps. Maybe ish.

The Sagentia report gives a nice breakdown of line lengths:
http://postimg.org/image/bp372fcnn/

<snip>

all that is required is a new line card.

A new linecard where?

100% they have a C-WDM MUX (I mean MUX not splitter) except the older ones where there isn't enough room to add a MUX or an additional modem so they need a baby cab. However, baby cab is not a big issue apparently. Due to the size of the estate we are talking I doubt that will be a big issue too.

Line lengths. Interesting. I had to adjust my figures a bit because they didn't fit with some other data. All a bit rough.

New line card? Existing cards are 2.5Gbps new cards are dual 2.5Gbps/10Gbps so for G.FAST the plan is to use the 10Gbps overlay. As mentioned elsewhere BT are testing 1Gbps. I bet that is because the vendor doesn't have an IC capable of doing it within the power envelope - would be my guess.

In reply to a post by Chrysalis:

so your example is gigabit per node not per street?

We will wait and see as to what happens as I think heavy users tend to congregate in certain areas such as student areas for example.

Yes. The backhaul BT are testing is point to point not a PON.

Heavy usage on cable in student areas is largely an upstream problem though, obviously, those guys take their toll to an extent on the downstream. Downstream is a different matter for obvious reasons; you can saturate upstream just by leaving a torrent client seeding, to saturate a big downstream you're either running MJ-12 or are one of those weird digital hermits who feels the need to try and mirror the contents of binary usenet groups onto their home storage.

As with FTTC Openreach aren't guaranteeing maximum performance, G.fast has a prioritised rate of 80Mb in the trials compared with 30Mb on production 80Mb FTTC.

A gigabit per node is fine.

Edited by deleted (Wed 09-Sep-15 08:23:58)

In reply to a post by WWWombat:

That's perfectly reasonable when you look at averages - especially at 1 Mbps per user.

It's still a bit worrying that only 3 users - out of hundreds - can saturate things.

It is but it generally works fine. It probably won't be more than 200 - 250 users and remembering that VM's top product has the lowest uptake of the product set the maths get more and more sane as you go.

Saturating 300Mb for any length of time isn't something that most do

Plenty of operators have been selling 300Mb+ on just over 600Mb of capacity with largely okay results, Virgin sold 100Mb on 152Mb in some areas without too much pain, small nodes.

Virgin's tests in Cardiff have been a good example of this - the areas in Cardiff have access to 800Mb however individual modems only have access to 400Mb of this, but it seems to be working even though it's far from ideal.

In reply to a post by Ignitionnet:

It is but it generally works fine. It probably won't be more than 200 - 250 users and remembering that VM's top product has the lowest uptake of the product set the maths get more and more sane as you go.

True - less than 20% takeup of the 100Mbps+ tiers will indeed make the maths more sane.

It raises a question as to what speed packages BT would intend to put over the G.fast nodes. Having lower packages will change the equation there too.

Saturating 300Mb for any length of time isn't something that most do

Also true. I take your point about the effect seeding has on upstream though. I can imagine that has a greater impact, both percentage-wise and overall duration.

Plenty of operators have been selling 300Mb+ on just over 600Mb of capacity with largely okay results, Virgin sold 100Mb on 152Mb in some areas without too much pain, small nodes.

I wonder how far BT will push it. Will they even endure a "little pain"?

Virgin's tests in Cardiff have been a good example of this - the areas in Cardiff have access to 800Mb however individual modems only have access to 400Mb of this, but it seems to be working even though it's far from ideal.

Interesting. How does the 800 get split? 2 distinct banks of 400? Or each modem randomly gets assigned 8 out of 16 possible channels?

In reply to a post by WWWombat:

Interesting. How does the 800 get split? 2 distinct banks of 400? Or each modem randomly gets assigned 8 out of 16 possible channels?

Usually load balanced into a pre-configured bank of 400, say a group on channel ID 1-8, another channel ID 9-16 and a last one 5-12 however vendors can implement as they please.

In reply to a post by Ignitionnet:

There's no CWDM splitter in the cabinets as far as I'm aware. They run on point to point Ethernet backhaul over a single fibre from what I gather which each connection running on a dedicated fibre, 1000Base BX-10. A CWDM splitter is not required to run GPON and XGPON on the same fibre. To backhaul the cabinets with XGPON requires new line cards as the existing ones do not support it.

Answered my own question.

There are CWDM muxes in some cabinets, however this is not the case for the vast majority. Where there are restrictions on deploying new fibre there's sometimes a 'parent' cabinet which takes a single fibre from the headend and feeds child cabinets via the different colours.

This is in no way related to PON of any kind. PON doesn't need CWDM, the kit is there because the cabinets are expecting point to point Ethernet, PON ensures they get what they expect. Were PON in use there would be simple passive splitters, not a powered multiplexer.

Every day is a school day.

Edited by deleted (Wed 09-Sep-15 14:25:36)

I am hearing words like "some areas" "largely ok" instead of "perfect".

I think VM are a bad example to say it works because it seems congested everywhere I look round here I see them as an example of failure not success. I know people first hand who get under 20mbps every evening e.g. on a 150mbit package. VM is ok if you pretend the bad areas dont exist.

On a national average people tend to not max out that sort of bandwidth you are right, but when you analyse things locally, you might e.g. have 10 people on one street doing what you said mirroring a news group or downloading every 4k torrent they can get their hand on. I do know a few people who seem "addicted" to downloading all the time.

I think 300mbit on 1 gigabit shared would work if policed, so e.g. if the unused capacity drops below 20% or 10% then police the downstream on users to drop the utilisation, this keeps latency and packet loss at proper levels, then I am ok with it.

Whilst if its left as a free for all I forsee problems. I do suspect openreach do have policing policies in place on cabinets which is why they quote prioritized speeds?

I cannot see myself ordering g.fast based on what I am hearing, I prefer 80mbit on shared 2.5gbit to 300mbit shared on gigabit. There is a reason openreach have no cabinet backhaul congestion, they got the contention levels right. Also I think they will be pushing for 500mbit at some point on g.fast and also trying to push for higher density nodes?

Edited by Chrysalis (Wed 09-Sep-15 14:34:29)

In reply to a post by Chrysalis:

I prefer 80mbit on shared 2.5gbit to 300mbit shared on gigabit. There is a reason openreach have no cabinet backhaul congestion, they got the contention levels right. Also I think they will be pushing for 500mbit at some point on g.fast and also trying to push for higher density nodes?

G.fast has a 'prioritised' rate of 80Mb.

Under congestion conditions it'll perform better than FTTC, it has far more bandwidth per subscriber and people don't suddenly start downloading the Internet when their speeds go up. The jump from 80Mb to 300Mb is far smaller, functionality wise, than for example the one I had from 1.3Mb to 60Mb.

300Mb on 1Gb will work fine regardless of policing until such a time when usage per subscriber rises dramatically. Right now it averages sub-1Mb/s per modem on FTTC. If super-busy areas are going enough to congest with 80Mb prioritised rate it's probably best to let them get on with it rather than trying to deliver 3-figures Mb/s per modem to deliver a congestion free service.

there may be higher "potential" speeds under congestion, but latency and packet loss is what I am referring to which happens when a host link gets full, these then can have unpredictable affects on traffic.

How often do you see "acceptable" levels of congestion? I only tend to see "acceptable" levels when policing is carried out. Sadly once congestion starts to occur things can go downhill very fast when is no policing system in place.

Is burst speed more important than everything else

You have to look past the averages, peak time demand is more important. Of course we will disagree on VM, I seen them as a failure in capacity management whilst you dont.

If we look past the people who download the internet (which I think is a fair few of them around me), the typical user's increase will probably come from with what they can get away with so e.g. in the past it may be the case the bill payer would ban kids from downloading in the evening so his/her netflix/iplayer works properly, but lets them rip over night, something like g.fast may stop households needing to do that kind of thing so as such peak time demand jumps up. It may also be we see 4k streaming become more popular (which is inevitable, youtube and netflix already involved in 4k streaming) this ultimately increases bandwidth consumption, we are also in an era where games distribution is fast moving to digital on consoles, things dont stay stagnated as you are suggesting, and if this is how isp's approach things its no wonder they keep getting caught out, you said it yourself both VM and BT have been caught out by utilisation at different points of time.

Where I agree with you is if there is only typical users on a node, there wont be a problem, that I am not arguing. The problem is if there is a bunch of people insisting on getting the max out of their connection clustered together on one node, then we have a problem without policing or extra capacity. I think this is especially possible when you have crowded households where can be easily 4 to 5 devices downloading at the same time. As it wont be that easy for a single device to pull 300mbit+ but quite easy for a few to do it.

So as i said I will keep my VDSL line maybe I will claw crosstalk back also if people hop onto the g.fast service.

Edited by Chrysalis (Wed 09-Sep-15 20:30:58)