You know... CIR philosophy would be a fantastic topic for this body to discuss (maybe you already have). CIR is often poorly understood which then results in poor and costly implementations. This isn't to say it can not be a very valuable product--just that folks often don't realize what they're asking for. CIR gets weirder in regulated environments like ours. Consider the "bitstream 2" service being defined by the TCF and CFH. Simply stated it looks like 30 m/s downstream, 10 m/s upstream, with 2.5 m/s up/down CIR. It sounds pretty good and straight forward. But examine what that means. Only 2.5 meg of what you send can be CIR. In a multi-flow data stream you will, of course, only want your delay sensitive/critical data to be tagged has high priority. Stop! What device is doing that tagging? The application on your PC? Your router? Your set-top (TV) box? This all implies the retail service provider is putting some sort of traffic prioritizing device in the home. That's extra cost to the RSP. Every bit stream service has a CIR definition--therefore Chorus has to build a network that can deliver CIR to every home in New Zealand whether an RSP wants to sell it or not. RSPs can certainly choose not to deal with the CIR component. What CIR does not do is give high priority tagging to the first 2.5 meg received and low priority for everything exceeding 2.5. This is often what customers expect when they hear "2.5 meg guaranteed". Low priority traffic (virtually everything a customer does) will contend for bandwidth just like it does today--which means in highly contended areas experience may be below 2.5 meg. The good news is that on the Chorus network, the CIR being "reserved" can be used to deliver low priority traffic when there is no high priority traffic to deliver. But there is still some bad news. For physical planning *everyone* has to be physically capable of delivering CIR sold. If every customer has 2.5 meg (whether the want it or not), then at about 4000 aggregate customers we have exceeded the physical capacity of a 10 gig handover. In order to get the benefit of the TCF/CFH defined SLAs, the RSP will have to purchase 10 Gig interface per 4000 subs regardless of the utilisation of those 10 gig links just to guarantee that CIR. Why does this matter to VDSL2? Well it is quite likely that NZ regulatory forces will require bitstream services to work exactly the same on VDSL2 as it does on UFB. So to answer your question about CIR on VDSL2--chances are very likely it will have a CIR component. But the real question is do you really want it for every service? Cheers! ~Curtis 027 655 5335 -----Original Message----- From: Jonathon Exley [mailto:Jonathon.Exley(a)kordia.co.nz] Sent: Thursday, 24 May 2012 5:39 p.m. To: Curtis Owings; nznog(a)list.waikato.ac.nz Subject: RE: [nznog] (no subject) I would like to see a CIR component for the VDSL2 service. Jonathon -----Original Message----- From: nznog-bounces(a)list.waikato.ac.nz [mailto:nznog-bounces(a)list.waikato.ac.nz] On Behalf Of Curtis Owings Sent: Thursday, 24 May 2012 1:52 p.m. To: nznog(a)list.waikato.ac.nz Subject: [nznog] (no subject) At grave risk of email execution... I would be interested in hearing about operational experiences utilizing Chorus transport. I would also be interested in the thoughts of this group on: -Ultra Fast Broadband -VDSL2 -Voice Services The separation of Chorus allows us to consider new inputs and options. My network has to meet your needs for service and revenue. Where is Chorus failing? What do you see a need for? I don't have direct control of field forces or the NOC, but hearing about these experiences helps me decide if the ops teams have the right tools and information to support the network. I can get them more tools and better information. I don't have a problem discussing these in a public forum. However, feel free to contact me privately. Curtis Owings Principal Solution Architect T +64 4 498 9355 (extn 49355) M +64 27 655 5335 E Curtis.Owings(a)chorus.co.nz Level 3, Deloitte House, 10 Brandon Street P O Box 632, Wellington www.chorus.co.nz P Please consider the environment before printing this e-mail ________________________________ This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002. _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog This email and attachments: are confidential; may be protected by privilege and copyright; if received in error may not be used, copied, or kept; are not guaranteed to be virus-free; may not express the views of Kordia(R); do not designate an information system; and do not give rise to any liability for Kordia(R).