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).

On 25/05/12 10:21, Jay Daley wrote:

Forgive me if I'm being a bit thick but some questions spring from that:

- By high priortity/low priority tagging do you mean at layer 3 IP (expedited forwarding in diffserv?) or layer 2?

- If a home router were to tag all egress traffic as high priority then would it work the way you say it wouldn't above - i.e. the first 2.5Mb/s guaranteed and the rest entering into contention.

- And would that high priority tagged traffic then win out over low priority traffic in that contention?

The LFC makes the distinction based on PCP bits, using PCP 4 to identify "Discard Ineligible" frames. If there's >CIR being sent, and the link is hitting congestion, then frames not marked, or marked with a different value, will be dropped first. If the the RSP or CPE don't mark any frames as discard ineligible, then the LFC can drop any frame it feels like. There's some good reading here: http://www.chorus.co.nz/ufbservices Specifically the base residential service description: http://www.chorus.co.nz/file/2007/chorus-ufb-services-agreement-service-desc...

So as a customer of an Internet service you get 2.5Mbs CIR, less whatever this L2 tagging filches from you as it has the first bite of the cherry? Committed in the first instance to the RSP/LFC, not you the customer.

I don't think the overhead due to VLAN tagging would be significant. The header:payload would be would be large for VoIP, but then for residential services I wouldn't expect much VoIP traffic anyway. For streaming video I would expect that full MTU packets would be used and so the VLAN tag overhead would be small. Jonathon. 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).

Hi Curtis, Yes 1ms burst isn't very helpful. I would expect that the intention of CFH was to specify that the Chorus network doesn't add more than 1ms jitter to traffic that is offered within CIR. Maybe the solution is to add something to the service spec along the lines of excluding jitter resulting from traffic bursts above CIR when measured with a 1ms time constant. The result of such shallow ingress buffering is that RSPs will need to shape to CIR rates below the CIR they are paying for. Cisco routers for example seem to have 4ms burst size at best, which I think means that the shaping will need to be done to 1/4 of the CIR. Just out of interest, what are the HSNS burst sizes? 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: Friday, 25 May 2012 2:36 p.m. To: nznog(a)list.waikato.ac.nz Subject: Re: [nznog] CIR on VDSL2

So many good, thought provoking questions.

Re: Jay Daley, Why not make all traffic High Priority?

The bitstream service definition is Layer 2 only. We'll be using P-bit markings to select frames as high priority or low priority.

You bring up an interesting suggestion. But the answer doesn't take too long to get to. If all your customers are sending you high priority traffic, then you won't be able to give your "real" high priority the handling it needs. While broadband data customers won't care about a few packet drops, there are some applications that really need high priority. Exactly how our current design handles contentious high priority traffic is something I want to pin down in detail before I respond--So I'll come back to it later.

Re: Jonathan Exley, What are Chorus' exact burst rates?

Well, they are pretty unforgiving. But let me explain why. CFH has set some very strict SLAs on the traffic handling Chorus is allowed to provide. The worst of these is a 1 ms of inter-frame delay variance (jitter). This is a very aggressive metric and forces the RSPs to then shape very tightly on to the Chorus network. If there was a genuine purpose to this metric, then I'd pull on my boots and slog in. But this metric was only generically selected as "good". While it sounds good, it is actually destructive. Chorus therefore can not allow RSPs to introduce frames to the wire all willy nilly--they have to be shaped to hit the wire inside the tolerance. Chorus is still hoping to work with CFH on this requirement so I don't want to provide exact parameters at this time. But I did want to say we are watching this very closely and we hope it is still negotiable. I don't like it either.

Re: Don Gould, Why CIR at all? Use PIR/BIR.

I think Don has a good point worth considering. From a Chorus perspective, we have been given instruction to only offer the products defined by the TCF and CFH. PIR/BIR could be brilliant, but it isn't what we were told to build. This is part of the reason I wanted to participate more in this list. I suspect the RSPs are not be represented well by the TCF and CFH. Philosophically, Chorus should only be enabling RSPs to offer choices to their customers, not dictating what their customers will get.

Re: All

Thanks for the good comments and replies. I don't have all the answers, but I now have more confidence that there are many experts in New Zealand to ask. My scope inside Chorus is design of transport. I can't promise to be able to get answers to all the marketing and product questions. But I will voice them internally.

~Curtis

--------------------------------------------------------------------- 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).

On Fri, May 25, 2012 at 9:59 AM, Curtis Owings 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

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

He probably means EIR/burst. Macca On 25/05/12 1:15 PM, "Jonathon Exley" wrote:

...

-----Original Message----- From: nznog-bounces(a)list.waikato.ac.nz [mailto:nznog- bounces(a)list.waikato.ac.nz] On Behalf Of Don Gould Sent: Friday, 25 May 2012 2:04 p.m. To: nznog(a)list.waikato.ac.nz Subject: Re: [nznog] CIR on VDSL2

[snipped]

...

I wonder if we're getting tied into CIR when we should be having a closer look at BIR and PIR?

BIR?

CIR = Committed information rate EIR = Excess information rate PIR = Peak information rate (CIR + EIR)

BIR is new to me - can you elaborate?

Jonathon. 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).

_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

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).