Hi All,
There has been widespread industry debate in the last week or so about DSL speeds. QSI Helpdeskers are having to field a number of complaints about speed issues, as are helpdesk staff from other ISPs. Tests carried out by QSI and others industry players have shown the current major speed constraint lies in the Telecom DSL backhaul network. This is affecting Quicksilver Internet, but it is also affecting the rest of
Hi Matt, You raise an important point here, in that all ISPs (with the exception of Xtra) SHOULD at some stage in Telecom's provisioning cycle reach the point where their ISP-Telecom PVC size is close to 24kbps per customer. If this is not the case, then Telecom is treating other ISPs differently to the way that it treats Quicksilver, which is of direct and immediate concern to me. This is something that I will investigate with Telecom and other ISPs. I'd welcome feedback from other ISPs here.... Furthermore, I say "with the exception of Xtra" as Xtra doesn't have an Xtra-Telecom PVC sized at 24kbps per customer. Its just another example of Telecom treating Xtra differently than every other ISP, and yet another reason for Structural Separation of Telecom. Mark -----Original Message----- From: Matt Camp [mailto:gargoyle(a)noise.net.nz] Sent: Thursday, 27 April 2006 2:03 p.m. To: Mark Frater Cc: nznog(a)list.waikato.ac.nz Subject: Re: [nznog] QSI / "industry" DSL problems caused by3.5mbit upgrades? Hi Mark, Thanks for taking the time to reply. While it's excellent to hear that you are upgrading various things, current user experience for QSI customers definitely seems to be slower than customers of other ISPs. There are certainly apparent congestion issues with some parts of the Telecom network (Mt Eden, for example), however the issues experienced by Quicksilver customers are happening right across the entire country, and all at the same time. Yet at the same time, customers of Ihug, Iconz, Orcon and Xtra are all able to get much higher rates... perhaps not the entire contracted rate, but not 10% (with wild latency). As many users both on and off this list have indicated, this points towards either congestion or a problem with the Quicksilver-Telecom PVC, however as we don't have any details here, we will have to trust that Quicksilver's own staff and processes are monitoring this closely, and have a much better picture of reality than a bunch of whingers on a mailling list :) It is, however, good to know that this is being looked at and will hopefully be resolved soon, as this whole business was started after being told that it was a Telecom problem which I had to deal with myself... Thanks to you and your staff for setting the record straight on that one. the industry.
There are (at least) three places in the constrain the bandwidth in their backhaul network, at the DSLAM, in the backhaul to the BRAS and at the ATM egress point to the ISP.
Telecom, by its own admission, now offers "no guaranteed minimum line speed performance" and their backhaul network is "dimensioned to ensure that all customers receive a minimum throughput reflecting the best efforts nature of the service."
For more background on Telecom's attitude on this topic, read Telecom's public wholesale informer:
http://www.telecom.co.nz/binarys/tw%202006-03-31d%20%20broadband%20lin e%20ra te%20speeds.pdf
12 April UBS public submission on IHUGs recent Determination application:
http://www.comcom.govt.nz//IndustryRegulation/Telecommunications/Whole sale/W holesaleDeterminatons/ContentFiles/Documents/Telecom%20Ihug%20Submissi on.pdf
Or to quote clause 70:
"With regard to SIR, and following the approach outlined in Decision 568 and the subsequent agreement with TelstraClear, Telecom has moved away from the concept of weighted SIRs introduced during the Decision
568 proceedings. All services simply share the same Virtual Path which is dimensioned to ensure that all customers receive a minimum throughput reflecting the best efforts nature of the service. All customers, retail and wholesale, compete equally in the same shared virtual path for the available bandwidth. Telecom has, however, retained the use of the VP scheduler to enforce fairness. The scheduler equitably allocates available bandwidth to all end users active at the time so that no end user can consume more that their share of the available bandwidth."
There have also been recent commentary in InternetNZ mailing lists and and NZDSL newsletter sent out today that focusses on the backhaul issues currently facing the industry.
This issue has also been a point of discussion between ISPANZ members in the last couple of weeks and ISPANZ is expected to put out an Information Brief in the next couple of days to highlight UBS/DSL backhaul as a industry wide issue that is delivering broadband customers the equivalent of dial-up speeds at peak times.
====================
To be fair, QSI does have some control over download speeds and we are continually reviewing and upgrading our network as our customer numbers grow.
1) We currently have a project underway to increase our Private Virtual Circuit (PVC) size from Telecom to manage future forecasted
growth.
Telecom controls the dimension of this PVC and constrains its size to 24kbit/s per customer. How this works in practice is that ISPs provide Telecom with a 3 monthly forward looking customer forecast. Telecom then resize the PVC based on this forecast. This process happens every couple of months, so the Unspecified BitRate (UBR) ATM PVC gets step increases every couple of months. We are expecting Telecom to complete the next speed increase on our PVC in the next couple of days.
2) We are also implementing a new L2TP Network Server (LNS) Architecture that will allow us to load share across a cluster of servers so that we can easily scale capacity sideways to manage future forecasted customer growth. This new system will be going live in the next couple of weeks.
3) We have recently tendered for more International IP Transit capacity and will be increasing our international bandwidth shortly to manage future forecasted customer growth.
Regards
Mark Frater Director, Quicksilver Internet
-----Original Message----- From: Steve Kurzeja [mailto:steve(a)a.geek.nz] Sent: Thursday, 27 April 2006 10:40 a.m. To: Regan Murphy Cc: nznog(a)list.waikato.ac.nz Subject: Re: [nznog] QSI / "industry" DSL problems caused by3.5mbit upgrades?
Regan Murphy wrote:
A friend of mine recently changed from Orcon to QSI. He is on an exchange on the other side of AKL from me. On the Thursday (with Orcon) he was sustaining a 220KB/sec download from the linux mirror at citylink. On the Friday when he was changed over to QSI he couldn't get better than 80KB/sec from the same source and he has had speed problems since. He changed about 2-3 weeks ago. From what you've said it does sound like QSI's UBS (ATM) circuit to Telecom is maxed out, rather than issues of over-subscription at the exchange. But it is hard to know without all the info. Perhaps someone from QSI could comment here.
Regan Murphy wrote:
As changing providers is a painful (and expensive) process I've been reluctant to switch without knowing for sure where the problem lay.
The churn fee is a lot lower now ( ~ $40 for a UBS to UBS reassignment).
Steve
_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog
-- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.385 / Virus Database: 268.5.0/325 - Release Date: 26/04/2006
-- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.385 / Virus Database: 268.5.0/325 - Release Date: 26/04/2006
_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog
-- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.385 / Virus Database: 268.5.0/325 - Release Date: 26/04/2006 -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.385 / Virus Database: 268.5.0/325 - Release Date: 26/04/2006