Afrihost Capped ADSL Feedback (MTN) - New beginning

[Unhappy1]

This problem has been around for 2 months or so now as threads across this forum can attest. What's the delay Afrigenie? Do we have an ETA on a fix?

Its taken 2 months for them to admit the problem is on their side, so maybe another 4 months before its fixed if we are lucky?

 

[Unhappy1]

Just to emphasis the Afrihost Chrome saga, it started here over two months ago

I have a strange problem - I am unable to access youtube and gmail via chrome but internet explorer is fine. What could be the issue?

A few weeks later we get the QUIC fix and Afrihost have their excuse and blame the problems all on google.

About one month ago:

Very interesting... I wonder if this is perhaps related to the widespread issues with Chrome at the moment.

http://mybroadband.co.za/vb/showthr...-beginning?p=15098406&viewfull=1#post15098406

Also:

Are you using Chrome by any chance? There have been significant issues with Chrome over the past few days, and Google is busy investigating the cause.

http://mybroadband.co.za/vb/showthr...-beginning?p=15098414&viewfull=1#post15098414

The community trys to explain that thats nonsense.

Hi DJ...

This is related to a comment and suggestion I made in the uncapped thread where a user was complaining about a capped 30kB/s rate on his YouTube videos. I commented and bet he was using Chrome and should switch to FF and use it's flash based player. He did and YouTube streamed perfectly.

This was an issue I picked up on Chrome as well. Videos playing with the HTML 5 player would just lock the downstream rate at a crazy low rate, yet in FF they would fly.


However what Afri* is forgetting here is that this is NOT a Chrome issue and Google ain't investigating nothing (from my googling anyway), because this problem ONLY exists on Afrihost's network. Only when using them as the ISP and using Chrome would this occur. I'm almost sorry I helped the user with my comment as it seems to have given them another avenue of excuses to hide behind.

ATT Afrihost: The problem is on YOUR side.

Deny, deny, deny

As far as we know it was related to a Chrome plug-in or extension. We didn't make any changes for the issue to be resolved.

More weird stories

One of the major technology universities (can't remember which) issued an communique on this. It seems it was related to UDP on an extension and was causing Google services in particular to act weird. Dunno if they fixed it on their side.

Still telling them they are wrong

No. It was not related to a plugin. If we are talking about the same user.

And the only problem related to UDP that Chrome has had was back in 2010 - which was a security and port problem which was fixed shortly after being reported.

I suggested a browser switch to the user because I had the same problems on your network only - not a perfect solution but then again I could not wait for you guys to fix it. This happens on Chrome on uncapped accounts when shaping is active btw. Does not happen often, but it does happen. I even reported this in a various tickets 2 years ago when Chrome was making the switch to HTML 5. Promises of it being investigated. Seems nothing happened relating to those claims.

And here

Not getting involved in an argument with you.

Those problems are not resolved by the way and they will occur again. That is the nature of an intermittent issue which exists on, you guessed it, your network only.

But of course nothing is wrong on your network. Just like how people cannot play games or stream realtime content the last three and half months and must just wait for these fixes to come - which they still have not. Contention issues? Of course they don't exist. Pfff. Just look at the network status indicator. All green. Good to go. All these complaints must be the user, the browser, the exchange or their imagination right?

Whatever. Glad I moved to a network that works and that I could at least help one user while he still struggles with you.

Dont want to take ownership

I can't take ownership of a problem we don't believe it not specific to us. From the reports we saw, it was happening only on Chrome, but to not only to Afrihost users.

A few weeks later, the problems still exist. I try and tell them again its their problem

The Chrome problem is related to Afrihost (even thought they don't want to admit it). I use Chrome with my other ISP's and it works perfectly.

http://mybroadband.co.za/vb/showthr...back-(Pt3)?p=15203374&viewfull=1#post15203374

Done "extensive testing" so it cant be us

From what I've seen, a few services and products seem to suffer from similar issues on Chrome I know we've had some extensive testing done on this, but haven't been able to pinpoint anything from our end that causes the issues.

Me again:

Well all i can say is its intermittent (without me changing any settings) and i've experienced zero issues on Telkom and Web Africa, so everything points to you guys. Forgive me if i put zero faith in MTN's "extensive testing".

Not us, not us, not us

It hasn't only been MTN's testing though, our team have been looking into this since it was brought up here.
If there was something we could tweak, change or turn on/ off - we would

UNTIL FINALLY, we get some kind of admittance that its not chrome its them

Disabling QUIC is definitely not a permanent solution, with that I can agree with you. This is only meant as an interim solution until our Team has resolved this permanently on the network side.

Afrihost if you want to know why your network is schite, its because you're a herd of ostriches.

 

[eddief1]

Afrihost if you want to know why your network is schite, its because you're a herd of ostriches.

...ongoing problems which last months point to one of two things...1)They don't know what is wrong, or 2) they simply don't have enough bandwidth! My guess is the latter

 

[Unhappy1]

...ongoing problems which last months point to one of two things...1)They don't know what is wrong, or 2) they simply don't have enough bandwidth! My guess is the latter

In the case of the Chrome problems its #1 , in the case of the general shaping and slow downloads its #2 imo.

 

[AfriMan]

This problem has been around for 2 months or so now as threads across this forum can attest. What's the delay Afrigenie? Do we have an ETA on a fix?

This definitely is not something we can change from our end. We're not shaping Capped accounts, so it would not matter how the traffic is classified. We've logged this several times with MTN and they also aren't able to find any network settings or devices that are acting on the traffic. We'll continue to look into this and engaging our partners to find out if there is more that can be done on our side.

 

[AfriMan]

Just run a few test with another ISP account - GEEZE you guys have a terrible backbone/traffic port prioritization network shaping device (whatever you want to call it). :wtf:

Never thought it was this bad

Not even the double data is making up for it anymore

We definitely don't think we have a bad network. My experience has always been that when the network is performing at optimum it's superior to others in terms of speeds and latency.

Right now, with demand problems which we're still trying to pin down, there are peak periods when the network under-performs, and it would be difficult to use that solely as the basis to say the network is poorly designed.

 

[AfriMan]

Just to emphasis the Afrihost Chrome saga, it started here over two months ago



A few weeks later we get the QUIC fix and Afrihost have their excuse and blame the problems all on google.

About one month ago:



http://mybroadband.co.za/vb/showthr...-beginning?p=15098406&viewfull=1#post15098406

Also:



http://mybroadband.co.za/vb/showthr...-beginning?p=15098414&viewfull=1#post15098414

The community trys to explain that thats nonsense.



Deny, deny, deny



More weird stories



Still telling them they are wrong



And here



Dont want to take ownership



A few weeks later, the problems still exist. I try and tell them again its their problem


http://mybroadband.co.za/vb/showthr...back-(Pt3)?p=15203374&viewfull=1#post15203374

Done "extensive testing" so it cant be us



Me again:



Not us, not us, not us



UNTIL FINALLY, we get some kind of admittance that its not chrome its them



Afrihost if you want to know why your network is schite, its because you're a herd of ostriches.

Firstly, you have a lot of time on your hands here. Would have taken me like a whole day to find all these quotes

I get that you are taking this as a personal issue because you reported it and have received feedback that you disagree with. But I think it's also important to remember that you seem to be coming from the perspective that we just don't feel like fixing things and we're too complacent to care. If you think about it, that makes no sense. Of course we want everything to work and for everyone to have a great experience. It's just good for business, reduces support queries, it's win-win all round. So for an issue to persist this long means that there are complexities that are not easily resolved. We're looking at this from all angles and there just isn't a quick fix or interim solution to make it go away. We've inspected traffic and interrogated the network for any rules, devices, software, etc that may conflict with this new type of traffic and so far we have not found anything from our side which is causing this. We'll keep looking and keep trying to ensure that everything works, and that our network delivers a great experience on every conceivable internet service possible.

I don't think name calling actually moves anything forward (though admittedly when I say we've tried everything, we haven't tried that, to be honest)

 

[AfriMan]

In the case of the Chrome problems its #1 , in the case of the general shaping and slow downloads its #2 imo.

Definitely not related to shaping, as we've mentioned several times. Capped is unshaped, so it's not relevant at all.

 

[AfriMan]

...ongoing problems which last months point to one of two things...1)They don't know what is wrong, or 2) they simply don't have enough bandwidth! My guess is the latter

I'll admit we don't know where the problem is. If it is on our network, we've searched through all our rules and protocols to find what could conflict with Google's experimental traffic and we've haven't found a source yet. We'll keep looking for anything that could be changed on our side that could improve our client's experience.

Definitely not related to capacity in any way.

 

[Sinbad]

I'll admit we don't know where the problem is. If it is on our network, we've searched through all our rules and protocols to find what could conflict with Google's experimental traffic and we've haven't found a source yet. We'll keep looking for anything that could be changed on our side that could improve our client's experience.

Definitely not related to capacity in any way.

Fact is that quic traffic seems to be structured a lot like torrent traffic- random udp ports, encryption etc.
So it's getting deprioritised...

 

[AfriMan]

Fact is that quic traffic seems to be structured a lot like torrent traffic- random udp ports, encryption etc.
So it's getting deprioritised...

If it's a question of priority, then I don't understand why the symptoms seem to be no service or horribly slow, unless there is also latency introduced, which could be the case. I'm thinking that if you are correct then using this traffic at peak times may also contribute additional latency where off-peak it may be less noticeable. Because the number of queries we've seen surely can't represent the entire Chrome community.

Still unsure of why it would also affect unshaped traffic though, but I'll leave that to the network guys who are investigating to improve this. I think everyone agrees that this is something we want to bed down ASAP.

 

[Sinbad]

Deprioritised traffic can be slow without being shaped. If you're near capacity on a link somewhere your low priority traffic will suffer badly even though there is no speed restriction on that type of traffic.

 

[AfriMan]

Deprioritised traffic can be slow without being shaped. If you're near capacity on a link somewhere your low priority traffic will suffer badly even though there is no speed restriction on that type of traffic.

I'll definitely mention this to the guys. Maybe it's somewhere they haven't thought to look. But that would mean we would see this problem only at peak usage periods, correct?

 

[Razotter]

Firstly, you have a lot of time on your hands here. Would have taken me like a whole day to find all these quotes

Wow, way to be condescending to your customers Afriman. Yes, this issue matters to us. A service we're paying for is giving us substandard performance and when we contact customer support we get the runaround. We have gone the extra mile to isolate the issue, test it with you, show you exactly what's happening, and the response is "Its not our problem, we definitely can't do anything".

If it is a problem that affects only your network, it is your problem.

The rate of transfer is consistent throughout download. If it was a load issue the transfer rate would fluctuate. It points glaringly to a deliberate (if unintentional) throttling of this specific traffic type.

 

[AfriMan]

Wow, way to be condescending to your customers Afriman. Yes, this issue matters to us. A service we're paying for is giving us substandard performance and when we contact customer support we get the runaround. We have gone the extra mile to isolate the issue, test it with you, show you exactly what's happening, and the response is "Its not our problem, we definitely can't do anything".

If it is a problem that affects only your network, it is your problem.

The rate of transfer is consistent throughout download. If it was a load issue the transfer rate would fluctuate. It points glaringly to a deliberate (if unintentional) throttling of this specific traffic type.

I see you're thread hopping here. So as I mentioned to you on the Uncapped thread where you pointed to deliberate shaping or throttling, I just want to point out that this does not make sense. If this was a shaping issue then it would never manifest on unshaped products. These are separate data pools, with entirely different rulesets, so the lifting of shaping on an Uncapped account making the symptoms go away, as you reported, would make no sense at all. So again, this requires more investigation to find out what could possibly work to get around this once we understand what is actually happening here.

I think the big question is why would we want to throttle Chrome traffic. With P2P and other types of data affecting demand, focussing on Chrome is not going to benefit us in any possible way. The amount of bandwidth will be negligible (in general terms) so it would be a complete waste of time to limit traffic on this service.

Just in general, if you're happy to make sarky comments to me, I would assume that you can handle one or two thrown back. If not's the case, I think I've failed Forums 101

 

[Worskos]

Hi Afri
Please tell me what is going on with my account.
4MB Capped account - Cape Town

WA Ping

Pinging www.mybroadband.co.za [197.242.89.170] with 32 bytes of data:
Reply from 197.242.89.170: bytes=32 time=32ms TTL=49
Reply from 197.242.89.170: bytes=32 time=35ms TTL=49
Reply from 197.242.89.170: bytes=32 time=33ms TTL=49
Reply from 197.242.89.170: bytes=32 time=34ms TTL=49

AH Ping

Pinging www.mybroadband.co.za [197.242.89.170] with 32 bytes of data:
Reply from 197.242.89.170: bytes=32 time=152ms TTL=51
Reply from 197.242.89.170: bytes=32 time=151ms TTL=51
Reply from 197.242.89.170: bytes=32 time=127ms TTL=51
Reply from 197.242.89.170: bytes=32 time=143ms TTL=51

WA Trace

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

  1    <1 ms    <1 ms    <1 ms  10.0.0.2
  2     *        *        *     Request timed out.
  3    13 ms    76 ms    81 ms  cdsl2-ctn-vl2473-ipc.ip.isnet.net [196.38.72.194
]
  4    11 ms    12 ms    25 ms  vlan2473.cdsl2-ctn.isdsl.net [196.38.72.193]
  5    26 ms    12 ms    12 ms  196.35.115.136
  6    11 ms    12 ms    12 ms  mi-za-cpt-p8-te0-0-0-0.ip.isnet.net [168.209.6.1
3]
  7    19 ms    16 ms    13 ms  css1-ctn-gi0-1.ip.isnet.net [168.209.2.10]
  8    11 ms    10 ms    11 ms  196.36.84.154
  9    38 ms    29 ms    29 ms  CORE.GP-CN-HET-MEE-1.TO.GP-HV-ICT-MEE-1.DFA.P2P.
10G.za.africainx.net [41.84.13.66]
10    29 ms    29 ms    29 ms  41-66-132-246-f6.HET001-CPE-1-to-GP-CN-HET-MEE-1
.africainx.net [41.66.132.246]
11    32 ms    30 ms    30 ms  core-access-switch1.jnb1.host-h.net [197.189.193
.1]
12    32 ms    38 ms    31 ms  row-access-switch1-row3-4.jnb1.host-h.net [197.1
89.193.36]
13    28 ms    29 ms    35 ms  www.mybroadband.co.za [197.242.89.170]

Trace complete.

AH Trace

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

  1    <1 ms    <1 ms    <1 ms  10.0.0.2
  2     *        *        *     Request timed out.
  3   173 ms   207 ms   294 ms  41.181.53.213
  4   163 ms   171 ms   168 ms  ipc-send-tb-3a.mtnbusiness.net [41.181.53.214]
  5   183 ms   140 ms   143 ms  tb-dca-2.za--qux-c.za.mtnbusiness.net [41.181.19
8.188]
  6   176 ms   172 ms   166 ms  unc-cpt-1.mtnns.net [196.44.18.8]
  7   162 ms   165 ms   164 ms  196.44.31.106
  8   155 ms   177 ms   156 ms  nl-ha-2.za--rb-cr-1.za-a.mtnns.net [196.44.0.121
]
  9   174 ms   179 ms   174 ms  africainx.cinx.net.za [196.223.22.47]
10   193 ms   201 ms   194 ms  CORE.GP-CN-HET-MEE-1.TO.GP-HV-ICT-MEE-1.DFA.P2P.
10G.za.africainx.net [41.84.13.66]
11   210 ms   239 ms   203 ms  41-66-132-246-f6.HET001-CPE-1-to-GP-CN-HET-MEE-1
.africainx.net [41.66.132.246]
12   190 ms   203 ms   201 ms  core-access-switch1.jnb1.host-h.net [197.189.193
.1]
13   204 ms   198 ms   192 ms  row-access-switch1-row3-4.jnb1.host-h.net [197.1
89.193.36]
14   170 ms   169 ms   157 ms  www.mybroadband.co.za [197.242.89.170]

Trace complete.

Please note:
1. I did the WA test first so this rules out what was suggested the last time that the WA performs better because the port got reset after the AH test.
2. Please DO NOT tell me that these 2 accounts are performing the same - They clearly aren't

 

[bgotapen]

2% packetloss and ping spikes around a year after I fist reported it to your "CORE NETWORK TEAM"

I am at a loss no pun intended on how a issue as big as packetloss can still not be resolved?

 

[whatwhat]

I think the big question is why would we want to throttle Chrome traffic. With P2P and other types of data affecting demand, focussing on Chrome is not going to benefit us in any possible way. The amount of bandwidth will be negligible (in general terms) so it would be a complete waste of time to limit traffic on this service.

So now you are saying that it isn't your network causing the issue?

 

[AfriMan]

So now you are saying that it isn't your network causing the issue?

What I've said is that we haven't located the cause of this on our network and we are continuing to look into this until we can fully understand what is behind this.

I think that is what I said ....

 

[AfriMan]

Hi Afri
Please tell me what is going on with my account.
4MB Capped account - Cape Town

WA Ping

Pinging www.mybroadband.co.za [197.242.89.170] with 32 bytes of data:
Reply from 197.242.89.170: bytes=32 time=32ms TTL=49
Reply from 197.242.89.170: bytes=32 time=35ms TTL=49
Reply from 197.242.89.170: bytes=32 time=33ms TTL=49
Reply from 197.242.89.170: bytes=32 time=34ms TTL=49

AH Ping

Pinging www.mybroadband.co.za [197.242.89.170] with 32 bytes of data:
Reply from 197.242.89.170: bytes=32 time=152ms TTL=51
Reply from 197.242.89.170: bytes=32 time=151ms TTL=51
Reply from 197.242.89.170: bytes=32 time=127ms TTL=51
Reply from 197.242.89.170: bytes=32 time=143ms TTL=51

WA Trace

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

  1    <1 ms    <1 ms    <1 ms  10.0.0.2
  2     *        *        *     Request timed out.
  3    13 ms    76 ms    81 ms  cdsl2-ctn-vl2473-ipc.ip.isnet.net [196.38.72.194
]
  4    11 ms    12 ms    25 ms  vlan2473.cdsl2-ctn.isdsl.net [196.38.72.193]
  5    26 ms    12 ms    12 ms  196.35.115.136
  6    11 ms    12 ms    12 ms  mi-za-cpt-p8-te0-0-0-0.ip.isnet.net [168.209.6.1
3]
  7    19 ms    16 ms    13 ms  css1-ctn-gi0-1.ip.isnet.net [168.209.2.10]
  8    11 ms    10 ms    11 ms  196.36.84.154
  9    38 ms    29 ms    29 ms  CORE.GP-CN-HET-MEE-1.TO.GP-HV-ICT-MEE-1.DFA.P2P.
10G.za.africainx.net [41.84.13.66]
10    29 ms    29 ms    29 ms  41-66-132-246-f6.HET001-CPE-1-to-GP-CN-HET-MEE-1
.africainx.net [41.66.132.246]
11    32 ms    30 ms    30 ms  core-access-switch1.jnb1.host-h.net [197.189.193
.1]
12    32 ms    38 ms    31 ms  row-access-switch1-row3-4.jnb1.host-h.net [197.1
89.193.36]
13    28 ms    29 ms    35 ms  www.mybroadband.co.za [197.242.89.170]

Trace complete.

AH Trace

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

  1    <1 ms    <1 ms    <1 ms  10.0.0.2
  2     *        *        *     Request timed out.
  3   173 ms   207 ms   294 ms  41.181.53.213
  4   163 ms   171 ms   168 ms  ipc-send-tb-3a.mtnbusiness.net [41.181.53.214]
  5   183 ms   140 ms   143 ms  tb-dca-2.za--qux-c.za.mtnbusiness.net [41.181.19
8.188]
  6   176 ms   172 ms   166 ms  unc-cpt-1.mtnns.net [196.44.18.8]
  7   162 ms   165 ms   164 ms  196.44.31.106
  8   155 ms   177 ms   156 ms  nl-ha-2.za--rb-cr-1.za-a.mtnns.net [196.44.0.121
]
  9   174 ms   179 ms   174 ms  africainx.cinx.net.za [196.223.22.47]
10   193 ms   201 ms   194 ms  CORE.GP-CN-HET-MEE-1.TO.GP-HV-ICT-MEE-1.DFA.P2P.
10G.za.africainx.net [41.84.13.66]
11   210 ms   239 ms   203 ms  41-66-132-246-f6.HET001-CPE-1-to-GP-CN-HET-MEE-1
.africainx.net [41.66.132.246]
12   190 ms   203 ms   201 ms  core-access-switch1.jnb1.host-h.net [197.189.193
.1]
13   204 ms   198 ms   192 ms  row-access-switch1-row3-4.jnb1.host-h.net [197.1
89.193.36]
14   170 ms   169 ms   157 ms  www.mybroadband.co.za [197.242.89.170]

Trace complete.

Please note:
1. I did the WA test first so this rules out what was suggested the last time that the WA performs better because the port got reset after the AH test.
2. Please DO NOT tell me that these 2 accounts are performing the same - They clearly aren't

What time did you run these tests?

We did see a significant in latency in the South last night during the peak period demand, but that would have started dying off before 10pm, according to my reports. Current latency in the south should be mostly normal, but we do usually see a brief spike in demand at 8am as businesses log on, though that is usually not accompanied by latency.

I still see latency on your line on both traces, so I still want to convince you that while our latency is sometimes poor during high demand, this is compounding an existing latency issue on your line. It may just be that the latency is far less noticeable when not added to by high demand on our network, but it may mean that your experience may be more affected than others who do not have this.