I'm more focussed on non-residential services where a CIR with EIR service would be useful. But CIR with no EIR (like BS2 and EUBA) would still be helpful for voice & video delivery. If an RSP is providing residential services then I would expect that the need for CIR would only be for VoIP home lines. So the CPE device would be provided by the RSP and they can set it up to do the appropriate dot1p marking. One benefit of having CIR + EIR is that the ingress burst allowance of Chorus services seems to be quite small. If I am trying to shape my traffic to fit the CIR but my egress bursts are larger than whatever Chorus will accept, I end up with dropped packets in my priority traffic class. Chorus could improve their services by allowing some EIR on the priority traffic class, and maybe also publish the burst allowance. Jonathon
-----Original Message----- From: Curtis Owings [mailto:Curtis.Owings(a)chorus.co.nz] Sent: Friday, 25 May 2012 10:00 a.m. To: Jonathon Exley; nznog(a)list.waikato.ac.nz Subject: RE: [nznog] CIR on VDSL2
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
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).