This is an issue that I think many people will be interested in both here and in .au. I've been following some of the specs on the NBN network that NBNCo have put out there. I don't understand how all of this traffic management is actually expected to work in the real world and as a result need all my data up to the PIR to move at up to PIR for the total duration of my subscribed service during peek times. (Ie if I want to pull 100Gb of datacap at 6pm tonight on my 100mbit HFC service then that's what I should be able to do, at 100mbit). http://www.geekzone.co.nz/forums.asp?forumid=44&topicid=101989&page_no=4#629734 This is hopeless on so many different levels it's just silly. The problem with layer 2 service classes (which is what I 'think' you're talking about) is how do I access them at layer 3 from an appliance in my network, eg an ATA? In Australia NBNCo seem to be attempting to address voice services by running a managed layer 2 service class directly to the FXO ports on their ONT. At layer 3, my edge router has QoS settings to give priority to the VoIP traffic from my ATAs, which tag the packets at layer 3 (if I'm correct and I confess my understanding is grey on this). The traffic here http://forums.whirlpool.net.au/forum/107 suggests I'm not the only one who still has trouble understanding exactly how this stuff should be set up to 'just work'. I wonder if we're even looking at the whole question correctly? I wonder if we're getting tied into CIR when we should be having a closer look at BIR and PIR? I also wonder about the dynamics of data caps? I wonder if the right products and product reporting are not being provided into the consumer market? As I see it, there are two basic ways I could be using my data. a. 24/7 b. in bursts Should regulation be based around providing more detailed information about what is going on in networks so consumers can just choose providers based on what is going on within their networks? Should regulation require all providers to deliver real time information such as Exetel in Australia do and the Karen weather map does? Should regulation simply require providers to keep services within the same service dynamic or give customers the option to exit any contract without penalty? To me, this talk of stuffing 4,000 customers into 10G with a 2.5mb CIR just doesn't make sense. Bevan Slattery calculated a while back that homes on the NBN will need 34mbit throughput during peek times. That's 13.6 times the CIR you're talking about. The dynamics of TCP obviously mean that we'll condense 34mbit throughput by a factor, but 14 times? 34mbit to 10G means ~ 300 customers and someone at Chorus clearly already gets that based on the fibre provisioning into the cabinets which I understand is 2 times 10G links. CIR works for folk who can push data about 24/7, but in the consumer market? I get the whole roading argument that we don't build roads to move cars at 100km/h at peek times. However in Wellington, if you don't want to crawl home at 5pm then you catch a train. If we're building 100mbit and 50mbit services on a GPON2.5 network which could deliver 1Gb to an ONT port, then is the real issue here that we're just trying to argue our way around only giving customers the ability to use 0.25% of the link capacity when they actually want to use it (peek time)? Let's translate that back to the Hutt road at 5pm - that's 0.25km/h or basically 'STOP' at peek times which will push people to the train, or in our case make service use pointless and as such mean customers will just not buy the services at all. Should we be regulating that providers will better define products as well? Should regulation require all providers to commit to the CIR their network will deliver at peek times for the duration of the consumers datacap? Or should the real discussion be around not trying to push 4k customers in to a 10G space and being more realistic about peek time throughputs, talking about 40G an 100G interfaces? Should we stop talking about how we're going to teach people to drive smaller cars, closer together with better ABS and other car smarts and simply invest that time, energy and money on expanding the Hutt road to 8 lanes? At 2.5mbit, you can not pull 1 SD video channel, a Skype call and RDT at the same time properly. This means that if my wife is watching TV and my mother calls wanting to chat to my son while I fix what ever problem has happened on her computer tonight we can't. The applications for faster BB are simple, understood and well defined, NBNCo spent $24m to figure all that out and a bit more... http://home.bowenvale.co.nz/wp/apps.gif In summary - in my view, the real issue here is CIR at peek times really needs to be far more realistic as a percentage of PIR rather than focusing on how we get smarter at pushing priority packets though a tiny hole, if we realisticlly expect customers to buy these new products at a price point we desire. D On 25/05/2012 11:11 a.m., Nicholas Lee wrote:
On Fri, May 25, 2012 at 9:59 AM, Curtis Owings
mailto:Curtis.Owings(a)chorus.co.nz> wrote: 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!
Tagging should not be a factor between edge devices. Why should you care about what my traffic is? If a service provider "promises" to deliver 2.5Mb CIF, then it is up to "me" the user to maintain the outbound - and to a degree inbound - traffic flows for my "critical" data within that boundary.
Nicholas
_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog
-- Don Gould 31 Acheson Ave Mairehau Christchurch, New Zealand Ph: + 64 3 348 7235 Mobile: + 64 21 114 0699