March 2005 - NZNOG - lists.nznog.org

RE: [nznog] telecom planning to break VoIP over its network?
by Olof Olsson 20 Mar '05

20 Mar '05

All, I believe the only "things" that Telecom have done to-date are: 1. To change the ADSL modulation speed to each subscribers "plan speed" + ATM overhead. For example, the 256/128 kbps plan has an ADSL modulation speed of 320/160 kbps (downstream/upstream). 2. Always have ADSL interleaving on, with a relatively long interleaving delay. Interleaving is used between the ADSL modem and the DSLAM to improve error correction performance against burst errors. The above means: *** An interleaving delay of approximately 28 ms is introduced *** A serialisation delay of approximately 3-50 ms is introduced (64 - 1024 byte packets). In other words, the total one-way latency is approximately 36 - 83 ms depending on packet size. Jitter will of course increase as latency increses. (Packets arriving behind large packets etc.) Which is bad for VoIP. The question is: did Telecom do this to make VoIPoUBS harder to implement? (The latency and jitter could be significantly reduced by lowering the interleaving delay and by not limiting ADSL modulation rates. Interleaving is not needed if the subscribers local loop is of a reasonable quality.) --Olof

1 0

RE: [nznog] telecom planning to break VoIP over its network?
by Philip D'Ath 18 Mar '05

18 Mar '05

This sounds like a porky to me. That's a lot of effort to go to. Telecom are a revenue generating company. Do you spend lots of try trying to devise methods to stop protocols working that you likely to be using yourself long term, or stick to spending your money on developing new products to generate more money. -----Original Message----- From: Joe Abley [mailto:jabley(a)isc.org] Sent: Friday, 18 March 2005 1:26 p.m. To: nznog Subject: [nznog] telecom planning to break VoIP over its network? http://www.pbs.org/cringely/pulpit/pulpit20050317.html "And there are other dirty tricks available to broadband ISPs. Telecom New Zealand, for example, is reportedly planning to alter TCP packet interleaving to discourage VoIP. By bunching all voice packets in the first half of each second, half a second of dead air would be added to every conversation, changing latency in a way that would drive grandmothers everywhere back to their old phone companies. This is because phone conversations happen effectively in real time and so are very sensitive to problems of latency. Where one-way video and audio can use buffering to overcome almost any interleaving issue, it is a deal-breaker for voice." _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

4 5

RE: [nznog] telecom planning to break VoIP over its network?
by Philip D'Ath 17 Mar '05

17 Mar '05

Its quite the opposite actually. It's much better to drop VoIP packets on VoIP codec streams (aka RTP streams) than it is to queue them. From my experience you can loose about 30% of the packets on a G.711 RTP stream within minimal impact on the voice itself. Queuing them on the other hand causes the jitter buffers to start extending themselves to compensate in the variations in latency caused by the buffer. This leads to a lag between when you speak and you hear the other person responding on the other end responding to you. I find rate limiting works best for UDP and traffic shaping works best for TCP. ps. UDP streaming applications don't re-transmit packets. If your doing something real time and you loose the packet, you loose the packet. This can lead to the video becoming jumpy, or the audio breaking up. -----Original Message----- From: Erin Salmon - Unleash Computers Ltd [mailto:erin(a)unleash.co.nz] Sent: Friday, 18 March 2005 2:40 p.m. To: nznog(a)list.waikato.ac.nz Subject: RE: [nznog] telecom planning to break VoIP over its network? In regards to Craig Spiers' comments, I doubt Telecom would see any amount of processing power as justification not to render VoIP useless on their networks. 20,000 Skype users must be hurting them. I think you can be 99.9% confident that IDGs statements about UBS are correct. Try using a VoIP application on a UBS line, especially during peak times, and you'll see what I mean. In order to cap the speed to 256kbps Telecom does just drop packets. I understand this is a limitation of the current hardware at the exchanges, and that it will be replaced at some point in the future by equipment which can queue packets instead (probably when they roll out ADSL2+). While queuing packets isn't fantastic for VoIP either, it's a step forward from dropping them altogether. Queuing is certainly more efficient for ordinary TCP and even streamed UDP traffic, because data doesn't need to be resent from the source. NZ needs some competition in the Telco market.

1 0

ConceptNET AS17474
by Craig Spiers 17 Mar '05

17 Mar '05

For those of you peering with ConceptNET please update your prefix lists. Changes: Updated 202.150.96.0/20 to 202.150.96.0/19 (currently advertised as 2x /20) Full Prefix List: ip prefix-list conceptnet-domestic-ape description ConceptNET Domestic Routes VIA APE <craig(a)concept.net.nz> ip prefix-list conceptnet-domestic-ape seq 5 permit 202.150.96.0/19 ip prefix-list conceptnet-domestic-ape seq 10 permit 202.127.8.0/22 ip prefix-list conceptnet-domestic-ape seq 15 permit 203.97.44.0/24 ip prefix-list conceptnet-domestic-ape seq 20 permit 202.7.5.32/29 ip prefix-list conceptnet-domestic-ape seq 25 permit 202.7.6.32/29 Regards, Craig - ConceptNET

1 0

Upcoming Webcasts on R2.co.nz
by Richard Naylor 17 Mar '05

17 Mar '05

After a hectic few weeks of webcasts, heres whats coming, so that you can be prepared. Saturday 26 March - a wedding in Carterton. Not expected to cause any major traffic flows. But I'm sure they'll drink beer at the reception (just to keep this on topic). Theres lots of video of the past few events going up at the moment. We hope this will include footage of the 30minute "World of Bendon" dance routine from Girl's Day Out. (is that in our terms of reference ? do I get extra bonus points ?) rich

1 0

Re: Re: [nznog] telecom planning to break VoIP over its network?
by Ian McDonald 17 Mar '05

17 Mar '05

> So why would Telecom behave any different in a LLU world? Because they would have to. > Sure, pick a > metric and we'll be a modest percentage better off, however people will still > be complaining, and we still won't have what we really want. > Depends what you mean by modest percentage. The whole point of LLU is that other companies can start using their own equipment - and they do. Witness the growth in Australia, USA and the UK where LLU along with a heavy regulation environment is seeing much higher speed delivered to users then here in NZ. > Spend the time, effort and money on building networks, not chasing, > implementing and then fighting to actually get something useful from LLU. > I'm an observer, not an ISP but understand what you are saying here. I agree we won't be the same as other countries due to our geography but at least we would achieve real results in Auckland.... (which is not where I live). > Cheers, > Jonny. > > I'll stop here now before it goes (any further) into a flame war. Ian

1 0

Re: Re: [nznog] telecom planning to break VoIP over its network?
by Jonny Martin 17 Mar '05

17 Mar '05

> Of course Telecom will object against LLU as it DOES hurt their bottom > line and they are owned by shareholders. It really has to be a policy > decision by the government. So why would Telecom behave any different in a LLU world? Sure, pick a metric and we'll be a modest percentage better off, however people will still be complaining, and we still won't have what we really want. Spend the time, effort and money on building networks, not chasing, implementing and then fighting to actually get something useful from LLU. Cheers, Jonny.

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 17 Mar '05

17 Mar '05

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 various NZIX route servers (http://nzix.net/) 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 at an exchange, you can maintain at least one BGP session at all times and consequently a full set of routes. The update causing these changes had the following mail headers: - From: Andy Linton <asjl(a)citylink.co.nz> - Cc: - Subject: [CityLink #2108] Routing updates for WIX Route Servers (fwd) - Date: Fri, 18 Mar 2005 15:22:12 +1300 (NZDT) - Msg-Id: <Pine.LNX.4.58.0503181521560.19063(a)jennings.citylink.co.nz> NZRR Database Notification Department --- PREVIOUS OBJECT: route-set: AS9439:RS-ROUTES:AS17474 descr: Route set advertised to AS9439 by ConceptNET - AS17474 members: 202.150.96.0/20^20-29, 203.97.44.0/24^24-29, 202.49.250.0/24^24-29, 202.50.176.0/24^24-29, 202.127.8.0/22^22-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: craig(a)concept.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20040908 source: NZRR REPLACED BY: route-set: AS9439:RS-ROUTES:AS17474 descr: advertised to AS9439 by Craig Spiers - AS17474 members: 202.150.96.0/19^19-29, 202.127.8.0/22^22-29, 203.97.44.0/24^24-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: craig(a)concept.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050318 source: NZRR

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 17 Mar '05

17 Mar '05

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 various NZIX route servers (http://nzix.net/) 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 at an exchange, you can maintain at least one BGP session at all times and consequently a full set of routes. The update causing these changes had the following mail headers: - From: Andy Linton <asjl(a)citylink.co.nz> - Cc: - Subject: [CityLink #2107] Routing updates for APE Route Servers (fwd) - Date: Fri, 18 Mar 2005 15:21:36 +1300 (NZDT) - Msg-Id: <Pine.LNX.4.58.0503181521180.19063(a)jennings.citylink.co.nz> NZRR Database Notification Department --- PREVIOUS OBJECT: route-set: AS9560:RS-ROUTES:AS17474 descr: advertised to AS9560 by Craig Spiers - AS17474 members: 202.150.96.0/20^20-29, 202.127.8.0/22^22-29, 203.97.44.0/24^24-29, 202.50.176.0/24^24-29, 202.7.6.32/29, 202.7.5.32/29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: craig(a)concept.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050314 source: NZRR REPLACED BY: route-set: AS9560:RS-ROUTES:AS17474 descr: advertised to AS9560 by Craig Spiers - AS17474 members: 202.150.96.0/19^19-29, 202.127.8.0/22^22-29, 203.97.44.0/24^24-29, 202.7.5.32/29, 202.7.6.32/29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: craig(a)concept.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050318 source: NZRR

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 17 Mar '05

17 Mar '05

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 various NZIX route servers (http://nzix.net/) 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 at an exchange, you can maintain at least one BGP session at all times and consequently a full set of routes. The update causing these changes had the following mail headers: - From: Andy Linton <asjl(a)citylink.co.nz> - Cc: - Subject: RE: [CityLink #2105] AutoReply: Routing updates for WIX Route Servers (fwd) - Date: Fri, 18 Mar 2005 15:20:32 +1300 (NZDT) - Msg-Id: <Pine.LNX.4.58.0503181520070.19063(a)jennings.citylink.co.nz> NZRR Database Notification Department --- PREVIOUS OBJECT: route-set: AS9439:RS-ROUTES:AS9889 descr: Route set advertised to AS9439 by Maxnet - AS9889 members: 202.14.217.0/24^24-29, 202.27.204.0/24^24-29, 202.36.70.0/24^24-29, 202.37.72.0/24^24-29, 202.37.181.0/24^24-29, 202.50.167.0/24^24-29, 202.89.32.0/19^19-29, 210.55.29.0/24^24-29, 210.55.100.0/22^22-29, 210.55.104.0/22^22-29, 210.55.110.0/24^24-29, 210.55.155.0/24^24-29, 210.55.169.0/24^24-29, 210.55.214.0/24^24-29, 210.55.230.0/24^24-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: alastair.johnson(a)maxnet.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041008 source: NZRR REPLACED BY: route-set: AS9439:RS-ROUTES:AS9889 descr: advertised to AS9439 by Maxnet - AS9889 members: 210.55.230.0/24^24-29, 210.55.214.0/24^24-29, 210.55.169.0/24^24-29, 210.55.155.0/24^24-29, 210.55.104.0/22^22-29, 210.55.100.0/22^22-29, 202.37.181.0/24^24-29, 202.37.72.0/24^24-29, 202.36.70.0/24^24-29, 202.27.204.0/24^24-29, 202.89.32.0/19^19-29, 202.6.5.0/24^24-29, 202.49.141.0/24^24-29, 203.89.160.0/19^19-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: david.fox(a)maxnet.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050318 source: NZRR

1 0