[AusNOG] NBN and CVC

[Matthew Moyle-Croft]

> On 29 Jul 2017, at 8:23 pm, Trent Farrell <tbflists at gmail.com> wrote:
> 
> I've always assumed the reasoning was that it allowed for a simple way to plan your aggs when thinking scalability etc. Not defending the reasoning, it seems to be an ancient trunky way of thinking about architecture.

I suspect you’re right. TW aggregation was the same way.
> 
> I have little faith the big guys could handle the provisioning load that would land if CVC became more accessible though. Mess.

I don’t think it’d be much of a burden - I suspect that this is going to be less burden or could be made to be.  eg. if you’re big enough to be running multiple ports toward NBN then you can scale them up and the CVC will burst as required.  Otherwise you have to be in there hand managing CVC sizes all the time. 

MMC


> On Sun, Jul 30, 2017 at 11:01 AM Matthew Moyle-Croft <mmc at mmc.com.au <mailto:mmc at mmc.com.au>> wrote:
> Hi,
> I’m going to side step that entirely - I think it’s always interesting to look at other models, but at the moment we’ve got what we’ve got.
> 
> I did have some interesting responses - I think it’s pretty clear though that a p95 product for CVC would be popular and unlock a lot of options for ISPs.  It may mean a bit of a drop of revenue for NBN but not too much, but it’d definitely overcome a lot of the issues with congestion where ISPs can’t always keep up and/or predict some spikes.
> 
> MMC
> 
> > On 29 Jul 2017, at 4:19 pm, Mark Delany <g2x at juliet.emu.st <mailto:g2x at juliet.emu.st>> wrote:
> >
> >> Is buying the CVC in fixed amounts the right model?
> >
> > I've always wonder why it's been a speed-based system. It strikes me
> > that speed has always been a poor proxy for resources consumed and now
> > that model is just getting in the way.
> >
> > Would it be better and simpler to set the local-loop (LL) line speed
> > to the maximum the tech allows and charge on bits delivered to/from
> > POI to LL along with a flat rate for LL upkeep?
> >
> > Just like other utilities such as electricity and water.
> >
> > It's been shown that most people don't generally consume unlimited
> > amounts of data - they consume what they need. And, now that people
> > are well and truly comfortable with quotas on their service, moving to
> > a true resources-based system is hardly much of a mindset change like
> > it once might have been.
> >
> >
> > The advantages of this approach are:
> >
> > a) RSP scaling costs match revenue much better than a menagerie of speed
> >   proxies
> >
> > b) Consumers aren't penalized with slow speeds just because they are
> >   light users
> >
> > c) All consumers get the best speed experience possible and are thus
> >   likely to grow their usage which means quicker revenue growth
> >
> > d) No "chilling effect" on the development of high speed applications
> >
> > e) RSPs have no incentive to throttle consumers
> >
> > f) It makes pricing transparent to the consumer
> >
> > g) It takes NBNCo out of the performance discussion
> >
> > h) It lets NBNCo focus on continuously improving the LL
> >
> >
> > All that needs to be done is:
> >
> > a) Replace CVC with a quota/resource system to maintain an appropriate
> >   ROI on POIs. Basically $X per MB delivered.
> >
> > b) Replace AVC with a fixed LL upkeep/ROI fee
> >
> >
> > The main down-side is that given the MTM - it will expose the lower
> > speed services for what they are: vastly inferior to the higher speed
> > services. That might not be politically palatable under the current
> > regime.
> >
> > It will also more directly expose RSPs who under-provision rather than
> > what we have today which is to smear the blame between NBNCo and
> > RSPs. But that's a good thing, right?
> >
> > Of course the resources-consumed pricing could still be set absurdly
> > high to suit the politics of making the NBN "profitable" for a future
> > sale but that is obscured now with the complex pricing. It will be
> > much more transparent with a simpler resources system. Also a good
> > thing.
> >
> >
> > Mark.
> > _______________________________________________
> > AusNOG mailing list
> > AusNOG at lists.ausnog.net <mailto:AusNOG at lists.ausnog.net>
> > http://lists.ausnog.net/mailman/listinfo/ausnog <http://lists.ausnog.net/mailman/listinfo/ausnog>
> 
> _______________________________________________
> AusNOG mailing list
> AusNOG at lists.ausnog.net <mailto:AusNOG at lists.ausnog.net>
> http://lists.ausnog.net/mailman/listinfo/ausnog <http://lists.ausnog.net/mailman/listinfo/ausnog>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ausnog.net/pipermail/ausnog/attachments/20170729/4893edce/attachment.html>