October 2004 - NZNOG - lists.nznog.org

RE: [nznog] FYI: Telecom changes the ADSL playing field again...
by Donald Neal 20 Oct '04

20 Oct '04

Subscribers to this list should by now be well aware that the Acceptable Use Policy begins "The NZNOG mailing list exists to provide a forum for the exchange of technical information and the discussion of implementation issues that require cooperation among New Zealand network service providers. In order to continue to provide a useful forum for discussion of relevant technical issues, users of the list are asked to respect the following guidelines. 1. Discussion will focus on Internet operational and technical issues. 2. Discussion related to meetings of network service providers is appropriate. 3. Discussion unrelated to these topics is not appropriate." This does include, for example, discussion of the way QoS features are used in carrier-class networks. But ADSL-related threads on this list have a record of quickly becoming irrelevant to the list's purpose. Let's try and keep this on topic, please. - Donald Neal NZNOG list administrator Donald Neal |Presbyopia - inability to see what Technical Specialist | bishops are for. Operations Engineering | 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." ------------------------------------------------------------------------------

1 0

FYI: Telecom changes the ADSL playing field again...
by Craig Humphrey 20 Oct '04

20 Oct '04

This just came up in the NZ ADSL list: http://www.telecom.co.nz/content/0,3900,204368-201502,00.html Many of you (who work for ISPs) are probably already aware of this, but here's a quick summary: 1. Telecom moving the rate-limiting to the DSLAM and implementing new backend QoS. 2. Telecom apparently (pointed out by an NZ ADSL user) introducing a further 30ms of latency to ADSL connections (presumably due to new QoS). 3. JetStream Games realm and Remote.Office connections will now be limited to connection plan speed (due to the limiting being done at the DSLAM). Yes, this will impact the usage of the jetstreamgames.co.nz and ftp.paradise.net.nz(?) game/linux/bsd mirrors. Note: this is just a mixture of my interpretation and info garnered from NZ ADSL. I/we could be completely wrong :) Later'ish Craig

9 8

Re: [nznog] FYI: Telecom changes the ADSL playing field again...
by neil gardner 20 Oct '04

20 Oct '04

>>> Barry Murphy <barry(a)unix.co.nz> 21/10/2004 10:23:04 a.m. >>> >Telstra Clear already do this with their tempest service, if you purchase a >256k connection, check your router status and you'll see you are connected at >288k. They at least give 32k leaway. Not really - that 288k is 288k of ATM bandwidth... It translates (as best I can figure) to 31.32Kb/sec or 250.56kbits of real world transfer... So you're actually getting more than 256kbits of raw traffic, it's the TCP overheads that bring the number below 256. Cheers - Neil G (Reference : http://www.broadbandreports.com/information/kb/maximum+DSL+speeds/ATM) quoted below maximum DSL speeds Maximum DSL speed is a function of distance, the gauge (thinness) of the phone wire used in your locale, and the DSL technology employed. The fastest DSL now commonly available is ADSL, and it offers maximum download speeds of up to 7.1mbps and around 1.1m upload. Most residential ADSL is limited to 90-680k for download, depending on the Telco. SDSL currently has a max of 1.5mbps, but that is both up and down (symmetric). Other common rates are (in k bits per second) 640k/90k, 1600k/90k, 680k/680k for ADSL. Rule of thumb for converting speeds to something easier to understand: take the k bps, and divide by 10. This is the maximum transfer K per second you are ever likely to see in a browser download window. More accurately, divide by 8 and take off 13%, which is overhead from tcp/ip and, more importantly, ATM overhead. (DSL lines use ATM as an underlying data-transport protocol). Modems range from 2-5k a second, DSL lines from 10-500k a second, office computer interconnections are usually either (best case) 800k a second (10mbit) or 8000k a second (100mbit switched). NOTICE: This message contains privileged and confidential information intended only for the use of the addressee named above. If you are not the intended recipient of this message you are hereby notified that you must not disseminate, copy or take any action in reliance on it. If you have received this message in error please notify Allied Telesyn Research Ltd immediately. Any views expressed in this message are those of the individual sender, except where the sender has the authority to issue and specifically states them to be the views of Allied Telesyn Research.

1 0

Re: [nznog] FYI: Telecom changes the ADSL playing field again...
by Michael Hallager 20 Oct '04

20 Oct '04

> This makes a lot of sense, though, technically. Why connect the user at > 8Mbits/sec down and churn out a boatload of RF bollocks from the copper, > when they're only buying a 256Kbits/sec "broadband" connection? May as > well make it 256Kbits/sec right at the start. This will probably enhance > overall network stability somewhat. It does lead automatically to point 3, > however... Good point. Here I have to use two micro filters in series to have a useable phone. (On the ADSL line). Anyone else have this experience? Michael Hallager

1 0

RE: [nznog] FYI: Telecom changes the ADSL playing field again...
by Regan Murphy 20 Oct '04

20 Oct '04

>From: Juha Saarinen [mailto:juha(a)saarinen.org] >Sent: Thursday, 21 October 2004 9:39 a.m. > >What's so badly b0rk3d about DSLAM rate-limiting >and the new QoS implementation that causes latency >to jump like that? Anyone know? "QoS also provides mechanisms for the network to control the delay characteristics (both latency and jitter) of high-priority traffic. Together, prioritization and delay control enable the transmission of real-time voice and video streams." The key word there is "control" (not "reduce" or "limit"). Maybe the latency is applied by design rather than being a fault of the DSLAMs. -- Regan

1 0

Re: Re: [nznog] FYI: Telecom changes the ADSL playing field again...
by Jonny Martin 20 Oct '04

20 Oct '04

> What's so badly b0rk3d about DSLAM rate-limiting and the new QoS > implementation that causes latency to jump like that? Anyone know? If they're dropping the DSL line rate down to plan speed then your bits will take longer to wander to the exchange. It makes quite a significant difference when moving from 8 odd Mbit/s down to 256kbit/s downstream. Can't really take jibes at Telecom for this. If they are taking this approach, then the slower line rates will also mean less RF inteference in the cable binders, which means more robust [albeit slow and piddly] DSL connections. This is how most, if not all, providers work in Australia. Cheers, Jonny.

1 0

RE: Voyager changing AS number
by Booker, Chris 19 Oct '04

19 Oct '04

Hi, Notification that AS4740 Voyager will change to AS703 (MCI Asia Pac) on Thursday 21/10/2004 at 05.30. I am writing to you as the contact point for peering between your AS and our legacy AS 4740 (Voyager) at the Auckland Peering Exchange. If you are not the best contact for peering in your organisation I would appreciate it if you could pass this e-mail on to the right person. MCI acquired Voyager some time ago and we have recently built a new hub in Auckland. We are migrating our peering links to the new site. As part of the move we would like to change the AS on our side to AS703. Our routing policy with respect to your AS will remain the same - we will treat you as a national peer. We will advertise our New Zealand prefixes to you and we will advertise your prefixes to our New Zealand customers. Our peering committee is currently reviewing our peering arrangements in New Zealand and you may hear from a member of our engineering team in the future with regards to that review. Our proposed date time for migration is this Thursday at 0500 New Zealand time. The only change required at your end should be for you to change the remote AS from 4740 to 703. Our IP address will remain the same. I'd appreciate it if you could contact me to let me know if this works for you. Thanks for your time. Regards Christopher Booker Implementation Engineering MCI Australia Email <mailto:chris.booker(a)au.mci.com> chris.booker(a)au.mci.com Tel: + 61 2 9434 5967 Fax: + 61 2 9434 5970

1 0

Invitation to Cisco ISP Update Seminar
by Arron Scott 19 Oct '04

19 Oct '04

Hi all I have asked the List owner for his opinion on whether this may be construed as sales content, so I hope this does not find dis-favour with anyone. Cisco has our primary ISP Consulting Engineer for Australia/New Zealand in Auckland next week, and would be please to invite any ISP staff to attend the following Product Update and Technology Seminar. Attendance is at no cost, and morning tea is included. Please RSVP to browns(a)cisco.com if you would like to attend. ISP's Technology Update Dear All Cisco systems is pleased to invite you a ISP Technology Update Date: Wednesday 27th October Time: 9am to 12.00 Location: Level 16, ASB Building , 135 Albert Street, Auckland During this update we will cover; . IOS software enhancements . 7301 and 7206 NPE-G1. . 10K with PRE-2. . BRAS and LNS Platform update . New RADIUS functionality . Policy management and integration . SSG enhancements . Netflow developments . Core routing update . CRS-1 and IOS-XR . 12000 update RSVP: browns(a)cisco.com We look forward to your participation Arron Scott (CCIE #4099) Phone: +64(9)3551951 Systems Engineer Mobile: +64(21)883163 Cisco Systems New Zealand Ltd. Fax: +64(9)3584442 Level 25, 135 Albert St, Auckland eMail: ascott(a)cisco.com

1 0

SPF Records
by Craig Whitmore 19 Oct '04

19 Oct '04

Hi folks. We have noticed a number of domains in NZ have entered in their NS's domain.co.nz IN TXT "v=spf1 mx -all" This means domain.co.nz will never attempt to send emails at all. (but valid emails are trying to be sent). I've talked to a couple of domain holders who had this and they've fixed them but most said it was done ages ago and they where playing and never expected it to catch on (but it has a lot looking at the number) We (Orcon) have started to use SPF (for testing inbound email) and found it helps with identifying spam. _ALOT_ of people have published valid SPF records. Thanks Craig Whitmore Orcon Internet

11 14

Re: [nznog] SPF Records
by Ewen McNeill 18 Oct '04

18 Oct '04

In message <200410190425.i9J4PvGX007457(a)mailserv.waikato.ac.nz>, "Barry Murphy" writes: >I've wanted to setup SPF in the past but have always wondered what happens >when you have a roaming user sending via paradise for example. The best solution for roaming users is (SASL authenticated) relaying via a central mail server that is listed with SPF. Most commonly used mail clients (and some mail servers) will do SASL authentication these days, and many MTAs can be configured to do SALS authenticated mail relaying. Pushing mail through a central mail server like this is also useful if you are doing other processing on that mail server (eg, statistics, storing copies of messages, etc). >Would one need to know every internet facing ip for all ISP's mailservers? SPF also allows for "include" options, so that you can include (by reference) the SPF records published by the ISPs that are being used. You could, eg, "include" the SPF records of all ISPs used by roaming users. It'd be looser than ideal, but still much better than nothing. If that still isn't sufficient (eg, you have roaming users doing direct-to-remote-server SMTP), you could perhaps list all those ISP dialup subnets (in CIDR fashion). Again this is not ideal, but narrowing it down to a few /22s or even /20s compared with "the whole internet" is still an improvement. With some combination of these it should be possible to list a "much better than nothing" SPF record and then focus on tidying things up so it can be tighter (perhaps eventually down to just "v=spf1 mx -all"). More details at the SPF wizard: http://spf.pobox.com/wizard.html?mydomain=example.com Ewen

1 0