MWEB Uncapped ADSL - Official Q & A

[Valerion]

You obviously have a copy of the T&C that was not made available to me. In fact, I received no such T&C when I signed up for uncapped. Signup was done telephonically. Contract was emailed to me for signature and confirmation and when I looked at the T&C and told them that these conditions were applicable to shaped/capped accs, MWEB promised to call me back and to this day, I await that call

Here are the terms and conditions that come into effect on 30 April 2010.

http://www.mweb.co.za/legalpolicies/ProductsServices/ADSLTerms2010/tabid/1918/Default.aspx

Here are the old terms and conditions

http://www.mweb.co.za/legalpolicies/ProductsServices/ADSLTerms2010/tabid/1925/Default.aspx

You will have to take up the lack of those T&C with MWEB directly, but you can at least read them here.

MWEB only admitted that there was a problem when most of its ADSL base started complaining and instead of giving us some logical answers and explanations they tried to insult our intelligence and when this did not work, they finally spilled the beans about what's really happening....agree?

You say the problems are isolated? If that is so, why so many complain?

Happy people don't complain, nor do they habitually post about their happiness. Unhappy people complain. If you work with customers, you often only work with unhappy ones. Phone the happy ones and they will tell you "Wait until you hear from me".

And "most of their user base"? You certain about this? I don't recall thousands of separate individuals complaining, just a handful. I don't know how large MWEB's customer base on uncapped is, but I am pretty certain this is an overstatement.

You right, not all us actuall suck down the internet, some of use for actual work(VPN, Support, Maintenance, Mail Server, etc) and some us work at night cos most of the clientele and business we deal with don't keep our office hours, so when you have a need to work, you expect the throughput you paying for...agree?

Correct. But it has never been stated that you are guaranteed a certain throughput. You may have made that inference, but I cannot recall any explicit promise of throughput from MWEB. Perhaps you can refresh my memory on this? It has been stated several times that this is a contended service.

I dug an IPSec VPN tunnel between my work LAN and my home LAN, and I run both NoMachine (using SSH) and RDP sessions over it regularly. I don't have any problems with slowdowns on either of those, either in the daytime or after hours. And my work LAN is on a different ISP, so there is peering traffic involved. I use SSH a lot, sometimes (for fun) even the IPv6 tunnels I have both at work and at home, which both terminate in Amsterdam. Even though it's travelling twice over the international links, it is still usable (even if not fast).

Telkom won't sell a 384k service, bill you for it and give you a dialup...agree?

You clearly have not seen an ADSL line that runs a lot of errors. As long as there is data flowing over it, Telkom is happy with it, in my personal experience. They only state "Up to xxxxkbps", same as the wireless and cellular providers. If I only get 5/10/15/20 kB/s over my 3G connection, I am out of luck complaining to the cellular company. The point is, none of these actually have guarantees. Neither does MWEB. This is a CONSUMER-oriented service, a home service.

You won't expect a R300 home ADSL router to have the same features and capabilities as a R10,000 Cisco ADSL router. Or the same support infrastructure. Neither would you subject them to the same traffic loads and expect them to handle it in the same way. Similarly you can't expect a R220 ADSL service aimed at home users and a R500 business-grade service to have the same performance, even though both are sold as 384 kbps.

 

[bradlesliect]

I don't think anyone is saying MWEB is perfect - sabrewolfy had some pretty big problems with Mweb (see his earlier posts) but they've been resolved. It's important to realise the middle ground - companies aren't necessarily completely evil either. Not even Telkom and not even Mweb.

If this is true ...then why play both sides of the fence? Sabrewolf's problems were OBVIOUSLY very different from the rest of us and even though we are saying its NOT the same this dude was insisting that we wanted to do was whine and moan and badmouth MWEB not considering that we are complaining about a service that we are paying for but not getting. If MWEB cannot offer guarantees on service offerings then they should not offer it.

Agree?

 

[AntiThesis]

If this is true ...then why play both sides of the fence? Sabrewolf's problems were OBVIOUSLY very different from the rest of us and even though we are saying its NOT the same this dude was insisting that we wanted to do was whine and moan and badmouth MWEB not considering that we are complaining about a service that we are paying for but not getting. If MWEB cannot offer guarantees on service offerings then they should not offer it.

Agree?

Can't really agree - since I don't think there's anyone who hasn't received what MWEB promised. It's uncapped and it's unthrottled. As much as there are complaints from people not getting full line speed on their downloads (in and out of peak hours) there are success stories from people who are hitting at or close to their line speed. If you check out the "How many gigs" thread there are no people (that I saw anyway) who have pulled a tiny amount of data even - most of them seem to be sitting on the 50GB+ mark.

I think MWEB would absolutely love to provide everyone with enough speed to download 24/7/365 at full line speed. Imagine how happy people would be. They can't do that with the infrastructure in place while maintaining profitability and the godawful contention ratio concept that ISPs rely on (that's a whole other deal which I hate). They're trying to upgrade infrastructure as quickly as they can and overcome limits placed on them by the lack of LLU but there's only so much they can do short term.

The adoption strategy is easy enough - if someone isn't happy with uncapped, stop using it until it's a viable service. And nobody should presume that the experience of someone else is the same as theirs. Not for the good or bad.

For myself, I am loving Mweb - and that's a phrase that was about as unlikely to come from my mouth as Julius saying "Sorry, I've been a bit of an idiot." I posted this when all this started. But I have to hand to MWEB that they've done an incredible thing.

 

[Valerion]

If MWEB cannot offer guarantees on service offerings then they should not offer it.

Agree?

No. Please provide the written guarantees extended by Telkom for the ADSL line itself, as well as the service guarantee from another home (not business)-oriented ADSL ISP. Or any of the cellular or wireless providers. I cannot recall that ANY of them actually provide a guarantee beyond "best effort". Should home broadband by this argument them not be offered in SA at all?

 

[AntiThesis]

What I will say is that it would be pretty cool if ISPs (and companies) in general were more transparent. MWEB are kinda doing well with that at the moment but there's always a need for more information. Publically available contention ratios, a site that displays current shaping and bandwidth capabilities and so on would rock.

 

[bradlesliect]

@Valerion

Thanks for pointing me in the direction of the T&C effective 30 April, I will definitely make a concerted effort to read it.

The happy ones are the clients who most probably have ccts >1MB and there getting a max speed of 50k-90k is fine. Happy customers are also probably the ones not coming from the possibly problematic areas which MWEB have failed to recognise.

Yes, it is difficult to see errors on an ADSL circuit using a "R300 home use ADSL" router but when the line is reported to Telkom multiple times, no fault found and when you switch ISPs to check if its line of ISP and it turns out to be ISP what then? I am not sure how MWEB has designed QoS, fair-queueing, access-lists or preferred routes and traffic types but what I do know that every single site I browse to goes via PTA before it leaves the MWEB network. One would have thought the CINX peering would be used. Some time back it was said that its too expensive. So your connectivity from where ever you going from may look different to mine.

ADSL is not only bought for browsing and its rather a worry when it takes almost 2hrs to download a 30MB windows update.

I used to be a Cisco engineer and I currently still run one of the older ADSL routers(Cisco 877W). My router will tell me when there are errors on my DSL interface, ethernet or wifi port. I see none.

I have clients who run Cisco and LinkSys ADSL routers with Asterisk, VoIP, Citrix, VPN and other services and I have found that when I test my MWEB ADSL acc on these sites, there is definitely degradation in service.

 

[AntiThesis]

Oh, tracert to a couple places:

I've just posted the result for the sake of space, if you want more detail, say so and I'll post

Tracing route to mybroadband.co.za [41.203.21.136]
over a maximum of 30 hops:

14 51 ms 51 ms 51 ms mybroadband.co.za [41.203.21.136]

Tracing route to bbc.co.uk [212.58.224.138]
over a maximum of 30 hops:

13 274 ms 272 ms 269 ms virtual-vip.thdo.bbc.co.uk [212.58.224.138]

Tracing route to facebook.com [69.63.189.16]
over a maximum of 30 hops:
16 335 ms 336 ms 335 ms www-11-01-ash2.facebook.com [69.63.189.16]

 

[SabreWolfy]

MWeb now provides an additional forum support representative:

http://mybroadband.co.za/vb/showthread.php?227844-MWEB-Representation-Announcement

I've just browsed an unofficial MWeb thread where the MWeb rep. replied to a question within minutes. This level of support is impressive. I really can't see how anyone can accuse them of trying to deceive us or not providing answers. They appear to be doing as much as they can.

Additionally, the "how many gigabytes" thread makes for interesting reading too. It seems many people are downloading massive amounts of data per month on MWeb uncapped accounts.

I'm not an MWeb-groupie. I don't work for them. I'm in favour of complaining about service when appropriate, reasonable and justified.

 

[Valerion]

@Valerion

Thanks for pointing me in the direction of the T&C effective 30 April, I will definitely make a concerted effort to read it.

The happy ones are the clients who most probably have ccts >1MB and there getting a max speed of 50k-90k is fine. Happy customers are also probably the ones not coming from the possibly problematic areas which MWEB have failed to recognise.

Yes, it is difficult to see errors on an ADSL circuit using a "R300 home use ADSL" router but when the line is reported to Telkom multiple times, no fault found and when you switch ISPs to check if its line of ISP and it turns out to be ISP what then? I am not sure how MWEB has designed QoS, fair-queueing, access-lists or preferred routes and traffic types but what I do know that every single site I browse to goes via PTA before it leaves the MWEB network. One would have thought the CINX peering would be used. Some time back it was said that its too expensive. So your connectivity from where ever you going from may look different to mine.

ADSL is not only bought for browsing and its rather a worry when it takes almost 2hrs to download a 30MB windows update.

I used to be a Cisco engineer and I currently still run one of the older ADSL routers(Cisco 877W). My router will tell me when there are errors on my DSL interface, ethernet or wifi port. I see none.

I have clients who run Cisco and LinkSys ADSL routers with Asterisk, VoIP, Citrix, VPN and other services and I have found that when I test my MWEB ADSL acc on these sites, there is definitely degradation in service.

I will agree that I cannot get good throughput on certain protocols. Bittorrent especially is slow for me. However, HTTP has always been fast. With certain exceptions I normally get 300+kB/s on these. IPSec-embedded traffic and SSH is quite good for me, as is RDP traffic (though that's normally inside the IPSec tunnel).

As for routing - that is due to IPC. MWEB either needs to run two distinct network operations centres, one for the south of the country and one for the north, with a lot of duplicated equipment and personnel, then have Telkom terminate two separate IPC links, or they can run a single NOC and have a single IPC link servicing it. Since it's cheaper to buy IPC in bulk, the second option would be better for them. So in essence, all CPT traffic gets sent over Telkom's IPC network to the termination point in Victory Park. Traffic from here then gets routed out. From the termination point JINX is much closer than CINX.

The ADSL errors was simply used as an example of a case where Telkom can give a degraded service and still call it acceptable. It is a situation I had personally had to deal with, and that was the responses I got at the time.

 

[SabreWolfy]

The Red Queen Effect

The Red Queen Effect is the concept of running as fast as you can just to stay in the same place. This is applicable in many scenarios from evolution to, I think, bandwidth usage -- or the supply of a limited, finite resource.

MWeb offers uncapped bandwidth: download as much as you want (can). However -- and this is the critical point -- the supply is a limited, finite resource. There is not an unlimited supply in terms of capacity. We all know this, but I think we sometimes forget this. The more capacity MWeb supplies, the more people will download (The Red Queen Effect). They will never be able to over-supply and will always be playing "catch-up".

Therefore, the logical approach is to restrict a limited resource. They prioritize protocols. If they didn't, they would most definitely go out of business.

As more subscribers come online, the cake is divided into smaller and smaller slices. I don't think MWeb has (publicly) stated how small they can make your slice. So the low-priority protocols get squashed further and further, and people start to moan. New capacity will come online soon we are told. People will stop moaning and download more. More subscribers will come online. Protocols will get squeezed. People will moan. Wash, rinse, repeat. The tragedy of the commons, as someone has already pointed out. No greater conspiracy or malevolent ISP. Peace.

 

[MWEB]

Hi,

Some comments/clarifications from my side ...

@AntiThesis - most Facebook static content is cached locally on Akamai servers ... traceroute to www.facebook.com.

@Valerion - as current IPC pricing incl national transit it would be uneconomical to deploy multiple geographically dispersed links since you would be paying twice to move traffic nationally i.e. nat transit bundled in IPC + your own actual nat transit.

@bradlesliect - we employ a carrier-class BW mgmt system (little more advanced than access-lists) which as mentioned proportionately distributes avaliable capacity between active users relative to their package speed. If you are really insistant on having a 384 service that will provide line speed on all protocols (not just the priority ones), virtually all of the time, then use a 4096 package on a 384 line. As the demand/capacity ratio improves on our network in the future you can always downgrade again.

MWB.

 

[AntiThesis]

@Mweb Thanks for the clarification

Any chance of information junkies like myself and bradlesliect getting a site/somewhere within a client area to see live BW usage / shaping status / level of BW available to low-priority protocols? Or something like that anyway - more information is always cool to see. Though I do appreciate that some information is probably interesting to competition as well.

Thanks for the responses It's sleep time now. Flu needs to leave me.

 

[Gordon_R]

The Red Queen Effect is the concept of running as fast as you can just to stay in the same place. This is applicable in many scenarios from evolution to, I think, bandwidth usage -- or the supply of a limited, finite resource.

MWeb offers uncapped bandwidth: download as much as you want (can). However -- and this is the critical point -- the supply is a limited, finite resource. There is not an unlimited supply in terms of capacity. We all know this, but I think we sometimes forget this. The more capacity MWeb supplies, the more people will download (The Red Queen Effect). They will never be able to over-supply and will always be playing "catch-up".

Therefore, the logical approach is to restrict a limited resource. They prioritize protocols. If they didn't, they would most definitely go out of business.

As more subscribers come online, the cake is divided into smaller and smaller slices. I don't think MWeb has (publicly) stated how small they can make your slice. So the low-priority protocols get squashed further and further, and people start to moan. New capacity will come online soon we are told. People will stop moaning and download more. More subscribers will come online. Protocols will get squeezed. People will moan. Wash, rinse, repeat. The tragedy of the commons, as someone has already pointed out. No greater conspiracy or malevolent ISP. Peace.

I think the Wikipedia article on Evolutionary Arms Races is as relevant as the Red Queen analogy.

The ADSL situation is asymmetrical, with the ISP having some choices and more information than most users. At the same time users have the choise to defect from one ISP to another if they think the service will be better.

The demand vs supply balance changes during the 24 hour day, and some users will have to learn to 'adapt' to doing downloads between midnight and 6am. Over time an equilibrium will be established, though this may fluctuate if the costs vs benefits change abruptly.

There are also 'invasive aliens' whose aim is to download 100GB for R219pm, and would wreak havoc on the network if they were not restricted...

 

[Tanya35]

Hi,

Some comments/clarifications from my side ...

@AntiThesis - most Facebook static content is cached locally on Akamai servers ... traceroute to www.facebook.com.

@Valerion - as current IPC pricing incl national transit it would be uneconomical to deploy multiple geographically dispersed links since you would be paying twice to move traffic nationally i.e. nat transit bundled in IPC + your own actual nat transit.

@bradlesliect - we employ a carrier-class BW mgmt system (little more advanced than access-lists) which as mentioned proportionately distributes avaliable capacity between active users relative to their package speed. If you are really insistant on having a 384 service that will provide line speed on all protocols (not just the priority ones), virtually all of the time, then use a 4096 package on a 384 line. As the demand/capacity ratio improves on our network in the future you can always downgrade again.

MWB.

I would be interested to know if MWEB is prioritising www.speedtest.net.

 

[Blackhand]

@Mweb || @Mweb Representative
Is it possible to get Mweb related emails sent to my Gmail account instead of my Mweb email account? I don't use ISP email addresses as they aren't really all that permanent.

 

[Raedwulf]

*hiccup*

 

[rambo919]

needing to use a 4MB service on a 384 line is just plain BS, I for one dont appreciate the talking in circles, when something goes beyond being black and white someone is screwing someone else

 

[bradlesliect]

needing to use a 4MB service on a 384 line is just plain BS, I for one dont appreciate the talking in circles, when something goes beyond being black and white someone is screwing someone else

+10000000000000000

Me thinks we have been around the block enough times to know BS when we see it?

@Gordon ...you nice eliquently put Wikipedia explanation makes for good reading...thanks! HTTP traffic will ALWAYS have preference(24x7x365) Why? cos its http traffic, its what teh internet needs to survive, ppl need to view and get to sites in order to select downloads, so arguement dont really make any sense... how much more do you want us to "adapt"?

As for the comment that was made in a post about "defecting" to other ISPs ...this aint politics. Its the world of consumers and just as the Service Provider is protected, so are we.

In all fairness, I think ISPs are intelligent enough to indentify and monitor "high consumption" users. They are the authority and reserve the right to sniff traffic(types and quantities) on the user's service(stated in T&C) and intercept ANY data/information that they may feel infringes on their AUP, why have it place if you not going to enforce?

@MWEB blah...blah...blah...fish paste!

 

[MWEB]

I would be interested to know if MWEB is prioritising www.speedtest.net.

Hi Tanya35,

No we dont.

Speedtest.net happens to use http (tcp 80) thus its traffic would fall into the priority BW pool.

MWB.

 

[MWEB]

needing to use a 4MB service on a 384 line is just plain BS

Hi rambo919,

I'm merely indicating this may be an option for those that insist on near 24/7 line speed performance for bulk downloads (torrents, news, rapidshare etc.). A standard 384 package will not exibit this type of behaviour for bulk download activities, even in the future.

One needs to think of it as two accounts with differing minimum bulk download capacity allocations based on price, not 384 vs 4096. At R539 our 4096 package is not far off from the business/gold type 384 offerings on the market which come in at roughly R500.

MWB.