- NZNOG - lists.nznog.org

Re: [nznog] Telecom's "peering" change of heart really isn't
by Matthew Poole 28 Mar '07

28 Mar '07

On Thu, 29 Mar 2007, Alastair Johnson wrote: > Every ISP at Every IX? Does it end at ISPs? What about universities, > for instance? What about satellite networks where the uplink isn't > necessarily NZ based? > At their local (to their primary centre of operations) IX, obviously. And I'm envisaging xx,000 being a sufficiently high number that only the University of Auckland (with around 40,000 FTE students) would even come close. > Are you going to pay for my long haul circuits to Palmy? > Is your primary centre of operations in Palmy? No? Why would you peer in Palmy, then? > Doesn't sound like it would work so well, to me. If we said only the > "major" IXs, what happens when the poor guy in Christchurch signs up his > XX,000th customer and is forced to peer... but isn't getting access to > the Big Boys? > Realistically, how many ISPs that are based outside AKL/WLG stand any chance of getting 50+,000 users? Remembering that of the top five, unless something has changed a lot in recent times, only Xtra and the TCL stable are > 100k. > Regulated peering sounds very scary to me... > Only if one takes it to absurdity. If it's regulated in such a way that only the very largest players could be affected, and the requirement on which IX(s) is based around centre(s) of operations, it's easily defined, easily enforced, and as I said won't really affect anyone other than TCL and TCNZ. Oh, and on your point about universities, I think you will find that most (all?) of them already peer. UoA, which is far-and-away the largest university in the country, certainly peers at APE. -- Matthew Poole "Don't use force. Get a bigger hammer."

1 0

jumbo frames
by Ian Batterbee 28 Mar '07

28 Mar '07

Has anyone got any real world experience of the usefulness of jumbo frames on ethernet (ie, MTU > 1500 bytes). A number of 1000mbps interfaces support it, but it seems to be that it would only be useful if jumbo frames were supported and enabled on all equipment between the sending NIC and final IP destination, so I'm struggling to see how enabling it in just say the core of a network would be all that helpful.

8 7

John Backus passes away
by Richard Naylor 27 Mar '07

27 Mar '07

For those who are a little older.... John Backus, who lead the team that developed FORTRAN passed away last week. FORTRAN was originally developed for the IBM 704 and is regarded as one of the first high-level programming languages. He was involved in the development of ALGOL 58 and ALGOL 60. ALGOL was the first language that I learned, FORTRAN the second. Theres a good obit at NYTimes http://www.nytimes.com/2007/03/19/obituaries/20cnd-backus.html?ex=133204320… Its worth reading. Slashdot also has heaps, including.... FORTRAN was the first working high level compiler language; BASIC was the first working interpreter language. Very different underlying structures. Now COBOL was the second major high level compiler language, and it was very much a reaction to FORTRAN, so I suppose using parent post's logic, we can blame Backus for COBOL. But then that cheapens the contributions of the Girl Admiral (Grace Hopper) who gave us such wonders as the nanosecond wire, and MULTIPLY 2 BY 2 GIVING FOUR. For the youngsters out there: FORTRAN (FORmula TRANslator) was the break-through from machine language and assembly to a higher level language with a compiler. Everything we do now is based on this; I believe that many mission critical engineering libraries are still in Fortran (they were a few years ago) COBOL (COmmon Business Oriented Language, Compiles Only By Odd Luck) was the second successful high level language. Its major improvement over Fortran was getting rid of triphasic logic (branch on <0, or =0, or >0) in favor of boolean logic (branch on !0 or 0). Its most noteworthy failing was the requirement to use the period punctuation mark (full stop) to end sections. This was particularly a problem for girl programmers, since at the time getting into trouble because you missed a period had serious consequences. Cobol simply put too much emphasis on a nearly invisible and easily missed period. BASIC (Beginners All-purpose Symbolic Instruction Code) made two big advances: first, it attempted to span both engineering and business computing (doing each with the same degree of imprecision); second and more important, it introduced the concept of using an interpreter rather than a compiler. Good stuff, that. Yet another baby step toward tomorrow's virtual machines. Most noteworthy program ever written in Basic: Eliza. Most significant long term contribution: the reaction to its spaghetti coding style, from which Pascal and modern procedure based programming arose. </drivel> Rich off for a scotch and to read a few punched cards......

2 1

92/8, 93/8 allocated to the RIPE NCC
by Leo Vegoda 27 Mar '07

27 Mar '07

Hi, The IANA IPv4 registry has been updated to reflect the allocation of two /8 IPv4 blocks to the RIPE NCC in March 2007: 92/8 and 93/8. You can find the IANA IPv4 registry at: http://www.iana.org/assignments/ipv4-address-space Please update your filters as appropriate. Regards, -- Leo Vegoda IANA Numbers Liaison

1 0

Re: [nznog] jumbo frames
by Jonathan Woolley 27 Mar '07

27 Mar '07

>>> Can I see the maths behind this? If you're talking about packet >loss >>> due to congestion and not using TCP then you're probably right >> >>I assume he's talking about my TFRC math from >>http://wand.net.nz/~perry/max_download.php >> >>Assuming you've saturated your link, a one bit in 'n' is going to >take >>out one packet every so often (if it takes out more than that you're >not >>going to get anything much worth discussing over your link in the >first >>place). So increasing the MTU isn't going to make it more likely >that a >>packet is lost, it just means you need to retransmit a larger >packet. >> >>However, since you're using larger MTU's, it's going to take you >less >>RTT's to get back up to full speed on your link, and therefore your >link >>will spend more of its time going at full rate than if you had a >lower >>MTU (since it would require more RTT's at lower throughput before it > >>starts saturating the link again). Ahh, ok. That's an interesting scenario. I'll have a look at the link Jono

1 0

Re: [nznog] jumbo frames
by Jonathan Woolley 27 Mar '07

27 Mar '07

>>If you're fragmenting and drop one packet of a 4-packet-sequence you >waste >>the other 3 packets anyway as its gotta send the whole oversize >packet as >>multiple fragments all over again. My guess is that is his >reasoning - >>and seems fair... Sending a 9600byte packet in one frame, or fragmented into seven frames isn't really a meaningful test if you're trying to prove that jumbo frames are better when there is packet loss. In the real world, the non-jumbo frame setup would only send 1500 byte packets...

1 0

Re: [nznog] jumbo frames
by Jonathan Woolley 27 Mar '07

27 Mar '07

So the most common real world example in NZ is UBS. Take the subscriber's 1500byte packet, add a PPP header, an extra IP and UDP header (for L2TP) and two MPLS headers (inside TNZ's netowrk) and jumbo frames look pretty useful. As alluded to below, 802.1q and especially stacking of vlans are strong reasons, even more so if transported over MPLS (Martini/VPLS). Jono > > > >---- Original Message ---- >From: nznog(a)daork.net >To: NZNOG(a)list.waikato.ac.nz >Subject: Re: [nznog] jumbo frames >Date: Wed, 28 Mar 2007 15:04:56 +1200 > >>MPLS. >>VLANs. >>L2TP with 1500byte payloads. >> >>etc. >> >>On 28/03/2007, at 3:01 PM, Ian Batterbee wrote: >> >>> Has anyone got any real world experience of the usefulness of >jumbo >>> frames on ethernet (ie, MTU > 1500 bytes). A number of 1000mbps >>> interfaces support it, but it seems to be that it would only be >useful >>> if jumbo frames were supported and enabled on all equipment >between >>> the >>> sending NIC and final IP destination, so I'm struggling to see how >>> enabling it in just say the core of a network would be all that >>> helpful. >>> >>> >>> >>> _______________________________________________ >>> NZNOG mailing list >>> NZNOG(a)list.waikato.ac.nz >>> http://list.waikato.ac.nz/mailman/listinfo/nznog >>> >>> !DSPAM:22,4609daac107231355811551! >>> >>> >> >>_______________________________________________ >>NZNOG mailing list >>NZNOG(a)list.waikato.ac.nz >>http://list.waikato.ac.nz/mailman/listinfo/nznog

2 1

Notification of NZRR Database changes
by NZRR Database Notifications 27 Mar '07

27 Mar '07

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. --- PREVIOUS OBJECT: route-set: AS9560:RS-ROUTES:AS9503 descr: advertised to AS9560 by FX Networks - AS9503 members: 131.203.0.0/16^16-29, 161.29.0.0/16^16-29, 161.65.0.0/16^16-29, 202.53.176.0/20^20-29, 202.174.160.0/20^20-29, 202.191.32.0/20^20-29, 210.48.160.0/20^20-29, 123.108.144.0/21^21-29, 202.46.176.0/21^21-29, 202.78.240.0/21^21-29, 203.190.208.0/21^21-29, 202.37.48.0/22^22-29, 202.59.4.0/22^22-29, 202.124.106.0/23^23-29, 192.88.85.0/24^24-29, 192.133.31.0/24^24-29, 202.20.97.0/24^24-29, 202.27.208.0/24^24-29, 202.36.119.0/24^24-29, 202.36.183.0/24^24-29, 202.46.190.0/24^24-29, 202.49.106.0/24^24-29, 202.50.247.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: noc-minor(a)fx.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20070226 source: NZRR REPLACED BY: route-set: AS9560:RS-ROUTES:AS9503 descr: advertised to AS9560 by FX Networks - AS9503 members: 131.203.0.0/16^16-29, 161.29.0.0/16^16-29, 161.65.0.0/16^16-29, 166.65.0.0/16^16-29, 202.53.176.0/20^20-29, 202.174.160.0/20^20-29, 202.191.32.0/20^20-29, 210.48.160.0/20^20-29, 123.108.144.0/21^21-29, 202.46.176.0/21^21-29, 202.78.240.0/21^21-29, 203.190.208.0/21^21-29, 202.37.48.0/22^22-29, 202.59.4.0/22^22-29, 202.124.106.0/23^23-29, 192.88.85.0/24^24-29, 192.133.31.0/24^24-29, 192.195.219.0/24^24-29, 202.20.97.0/24^24-29, 202.27.208.0/24^24-29, 202.36.119.0/24^24-29, 202.36.183.0/24^24-29, 202.46.190.0/24^24-29, 202.49.106.0/24^24-29, 202.50.247.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: noc-minor(a)fx.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20070328 source: NZRR

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 25 Mar '07

25 Mar '07

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. --- PREVIOUS OBJECT: route-set: AS9439:RS-ROUTES:AS38292 descr: advertised to AS9439 by ZeroOne (NZ) Limited - AS38292 members: 202.174.6.0/23^23-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: noc(a)zeroone.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20070214 source: NZRR REPLACED BY: route-set: AS9439:RS-ROUTES:AS38292 descr: advertised to AS9439 by ZeroOne (NZ) Limited - AS38292 members: 202.174.6.0/23^23-29, 203.152.104.104/29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: noc(a)zeroone.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20070326 source: NZRR

1 0

Xtra accepting ping
by Michael Fincham 24 Mar '07

24 Mar '07

Is it just me, or did some of Xtra's servers (specifically alien.xtra.co.nz/www.xtra.co.nz but probably more) suddenly stop replying to echo requests at some point this afternoon? Certainly had me stumped/panicking when my traceroute died at the penultimate hop... -- --Michael Fincham Unleash Technology Solutions

1 0