On 25/05/2012, at 2:35 PM, Curtis Owings wrote:
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.
Is there a diffserv to P-bit mapping in there?
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.
Thanks for taking the time to reply, I look forward to the full details. cheers Jay
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
-- Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840