- NZNOG - lists.nznog.org

RE: [nznog] Acceptable levels of Latency, Jitter and Packet loss on national links
by Craig Humphrey 27 Sep '04

27 Sep '04

That's all well and good, but since it's also the only "performance metrics" given in the contract, it's all I have to go on (hence soliciting references from existing customers). It would be nice to get an indication of what performance we can expect, not just "oh, it'll never get worse than this..." I've got a load of questions for the provider around these (and other) issues, so I'll just have to see what they come up with. Later'ish Craig > -----Original Message----- > From: Joe Abley [mailto:jabley(a)isc.org] > Sent: Tuesday, September 28, 2004 2:54 AM [snip snip] > It may actually be that the performance guarantee is a paper-dwelling > construct, and has little or no form in the actual network. > > I have certainly come across providers in my past for whom > performance > guarantees were necessary in order to be able to bid for > projects, but > the cost of deploying infrastructure to support the > guarantees was much > higher than just giving a few refunds now and then. As such the > guarantees didn't really exist outside the billing department. > > > Joe

1 0

RE: [nznog] Acceptable levels of Latency, Jitter and Packet loss on national links
by Donald Neal 26 Sep '04

26 Sep '04

> -----Original Message----- > From: Joe Abley [mailto:jabley(a)isc.org] > Sent: Monday, 27 September 2004 4:09 p.m. > To: Craig Humphrey > Cc: nznog(a)list.waikato.ac.nz > Subject: Re: [nznog] Acceptable levels of Latency, Jitter and > Packet loss on national links > > > On 26 Sep 2004, at 22:25, Craig Humphrey wrote: > > > Latency Jitter IP Packet Loss > > "Realtime" <50ms <12.5ms <0.1% > > "Interactive" <75ms <50ms <0.1% > > "Business" <200ms <100ms <1.0% > > > > And yes, we're chasing references who are already using > this service. > > > > The reason for my dissatisfaction... Based on crude testing > with ping, > > we already get an average of 25ms latency over the 2Mbit/s fibre > > (during > > normal background load), and that's a round trip! So I'm > not sure how > > the above is really an improvement... > > What is the actual RTT over the ethernet service? Normal performance > and guaranteed performance seem very unlikely to be similar (or even > comparable within an order of magnitude). Among other reasons this is because normal performance is seen when things are normal. A provider's performance guarantee is presumably going to have a more demanding specification than just "you'll see numbers like this most of the time". - Donald Neal [All opinions mine only.] Donald Neal |World Domination is Technical Specialist |proceeding according to Operations Engineering |plan. - Andrew Tridgell Integration & Services Division +----------------------- Alcatel NZ Ltd - Telecom's network operations manager ------------------------------------------------------------------------------ "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." ------------------------------------------------------------------------------

2 1

Acceptable levels of Latency, Jitter and Packet loss on national links
by Craig Humphrey 26 Sep '04

26 Sep '04

Hi People, We're about to upgrade our site to site 2Mbit/s frame relay WAN links (Akl, Wgn & Chc) to 10Mbit/s fibre into a central cloud, but I'm not entirely happy with the performance levels our provider is offering us. Below I've listed what's on offer, but I wanted to see what other providers consider to be deliverable levels for National links. All thoughts and comments welcome, probably off-list (to keep the noise down), and I can post a summary if people are interested. Latency Jitter IP Packet Loss "Realtime" <50ms <12.5ms <0.1% "Interactive" <75ms <50ms <0.1% "Business" <200ms <100ms <1.0% And yes, we're chasing references who are already using this service. The reason for my dissatisfaction... Based on crude testing with ping, we already get an average of 25ms latency over the 2Mbit/s fibre (during normal background load), and that's a round trip! So I'm not sure how the above is really an improvement... Soon'ish Craig

2 1

Notification of NZRR Database changes
by NZRR Database Notifications 26 Sep '04

26 Sep '04

Dear Colleague, This is to notify you that some object(s) in NZRR database which you either maintain or are listed as to-be-notified have been added, deleted or changed. These objects are used to configure the APE and/or WIX route servers so you can expect the relevant servers to be reloaded in the near future. The reloading of the servers is staggered over a period of time so that if you are peering with both servers, you will maintain at least one BGP session at all times and consequently a full set of APE and/or WIX routes. --- PREVIOUS OBJECT: aut-num: AS24111 as-name: NZRR-AS24111 descr: NZwireless descr: initially peering at '202.7.1.69' descr: see Citylink RT job #929 admin-c: RPA1-NZRR tech-c: RPA1-NZRR import: from AS9439 accept ANY AND NOT fltr-bogons export: to AS9439 announce AS24111 notify: rpsl-admin(a)wix.net.nz notify: nznog(a)list.waikato.ac.nz notify: andrew.tipton(a)nzwireless.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)wix.net.nz 20040810 source: NZRR REPLACED BY: aut-num: AS24111 as-name: NZRR-AS24111 descr: nzWireless descr: initially peering at '192.203.154.14' descr: see Citylink RT job #1236 admin-c: RPA1-NZRR tech-c: RPA1-NZRR import: from AS9560 accept ANY AND NOT fltr-bogons export: to AS9560 announce AS24111 notify: rpsl-admin(a)ape.net.nz notify: nznog(a)list.waikato.ac.nz notify: andrew.tipton(a)nzwireless.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)ape.net.nz 20040927 source: NZRR --- PREVIOUS OBJECT: route: 203.110.28.0/23 descr: Route for NZwireless - AS24111 origin: AS24111 notify: rpsl-admin(a)wix.net.nz notify: nznog(a)list.waikato.ac.nz notify: andrew.tipton(a)nzwireless.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)wix.net.nz 20040810 source: NZRR REPLACED BY: route: 203.110.28.0/23 descr: Route for nzWireless - AS24111 origin: AS24111 notify: rpsl-admin(a)ape.net.nz notify: nznog(a)list.waikato.ac.nz notify: andrew.tipton(a)nzwireless.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)ape.net.nz 20040927 source: NZRR --- OBJECT BELOW CREATED: route-set: AS9560:RS-ROUTES:AS24111 descr: Route set advertised to AS9560 by nzWireless - AS24111 members: 203.110.28.0/23^23-24 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)ape.net.nz notify: nznog(a)list.waikato.ac.nz notify: andrew.tipton(a)nzwireless.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)ape.net.nz 20040927 source: NZRR

1 0

RE: [nznog] nznog research group for NGI?
by Donald Neal 26 Sep '04

26 Sep '04

> -----Original Message----- > From: Daniel Lawson [mailto:daniel(a)wand.net.nz] > Sent: Thursday, 23 September 2004 9:41 a.m. > To: jon.brewer(a)worldnet.att.net; nznog(a)list.waikato.ac.nz > Subject: Re: [nznog] nznog research group for NGI? [...] > The NZ Advanced Network is not about reading webpages. It's not about > downloading mp3s or using Kazaa. It's about shipping multi-gigabyte > volumes of data between research organisations. It's about developing > the next generation of network apps that will rely on this > capacity of > transit. > > As for 15 c/MB charges at Victoria, we face similar charges > at Waikato. > It's one of the reasons we (as a network research group) want this > network - not because we care overly about paying to read > Slashdot every > morning, but because 15 or 10 even 1 c/MB is far too much > when you want > to send 600 GB of network traces to Auckland. And it'll take > too long > across a 10Mbit TC ethernet connection. You know, talking about what specific users plan to do with a research network might actually be operational content, and so on topic for this list. - Donald Neal Donald Neal |World Domination is Technical Specialist |proceeding according to Operations Engineering |plan. - Andrew Tridgell Integration & Services Division +----------------------- Alcatel NZ Ltd - Telecom's network operations manager ------------------------------------------------------------------------------ "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." ------------------------------------------------------------------------------

2 1

Sprintlink- Planned Outage Notification
by Jonathan Brewer 25 Sep '04

25 Sep '04

Folks, This came from one of our providers, and I hadn't seen mention of it on the list. Not that 5min is any big deal, but it's nice to know why the pager is going off in the middle of the night. Cheers, JB Dear Valued Customer, Sprintlink, our upstream provider has notified us of an upcoming outage caused by Telecom NZ Ltd performing scheduled maintenance work. Details are as follows: Start date: 3 Oct 04, Sunday Time: 00:01 hrs End date:3 Oct 04, Sunday Time: 01:01 hrs Duration: One 5 minute outage during this window. Reason: Maintenance work by TNZ

1 0

APNIC records to be marked as 'private' for end user delegations
by Mark Foster 23 Sep '04

23 Sep '04

http://www.apnic.net/docs/policy/proposals/prop-007-v001.html http://www.apnic.net/info/faq/privacy-faq.htm As at 30 September client-side delegation information will be hidden from whois - the only info provided will be the ISP involved. Suprised there hasnt been any discussion of this on here so thought id pass it through. (original information sourced via NANOG, where theyre now busy 'discussing' the merits of making life easier for spammers, etc.) Cheers Mark. [posts are imho, as usual]

1 0

new BIND releases today
by Joe Abley 23 Sep '04

23 Sep '04

Fresh out of the oven: BIND 9.3.0 BIND 9.2.4 BIND 8.4.5 For more information, see: http://www.isc.org/sw/bind/ http://www.isc.org/sw/bind/bind9.3.php Joe

5 7

International routing issues yesterday
by Tom Hibbert 23 Sep '04

23 Sep '04

Hi guys, We were stung by a routing issue yesterday affecting us and many of our customers unable to reach most international hosts. Our clients are with lots of different ISPs, and so far we have had confirmation from Orcon (thanks Craig) that there was an issue with the Global Gateway. I'd appreciate if someone from VISP or Iconz could confirm that they were affected too. I know getting an official report from Telecom or GG will be next to impossible, but it would be great if someone from there could tell me which endpoint was affected. Thanks in advance :) Tom Hibbert Technical Specialist Phone: +64-9-306-0230 Technical Helpdesk: +64-9-306-0234 Mobile: +64-274-307-784 Email: tom(a)nsp.co.nz Website: http://www.nsp.co.nz The information in this email and any attachments is confidential. This information may be subject to legal, professional, or other privilege. It must not be disclosed to any person without our authority. If you are not the intended recipient you are not authorised to and must not disclose, copy, distribute, or retain this message or any part of it. Please return this message to the sender immediately and delete any and all copies from your system.

1 0

TelstraClear WIX/APE de-peering and national/international cost split
by Bruce Fitzsimons 22 Sep '04

22 Sep '04

Hello list. As a TC Cable customer I'm curious about what the impact of the TC de-peering is going to be on my monthly bill. They've previously announced (and I believe its still on their FAQsite) that they may revisit the current 1:10 cost differential between international and national traffic at some time in the future. I'd hazard a guess that the de-peering may provide some impetus for this, since national traffic sources who don't pay to peer with them may cost them more money. It'd be nice of course if that meant they reconsidered their peering policy, but I won't hold my breath. Anyone heard anything? Have I got the peering cost equation the wrong way around? /Bruce

1 0