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