Akamai and streaming data - traffic management problem(s) are NOT fixed :-(
Oh dear ... still no change(s) to correct this fundamental PN traffic management problem then 
The following graph documents data transfer when playing a random 4oD programme between 1857 and 1903 hours tonight:
As can clearly be seen, the data transfer rate was instantly reduced to sub dial-up speeds at EXACTLY 1900 hours. However, there does not appear to be anything of any relevance that corresponds to either the timing of this event or the effect of this event documented in the portal help pages for traffic management on my A/C. In fact it doesn't really appear to correspond to any documented rate limit for any service on any A/C type. So, I think some definitive explanation of exactly what traffic management PN are actually doing is required:
(1) Please confirm that the following table [**] allegedly documenting traffic management/shaping for my A/C type is entirely correct or advise on any relevant corrections and/or any additional traffic categories that there may be:
(2) Please define exactly what constitutes a "download site" and list all relevant domains/IPs that currently fall into this category or provide a link to a fully comprehensive and up-to-date list.
(3) Please define exactly what constitutes a "download server" and list all relevant domains/IPs that currently fall into this category or provide a link to a fully comprehensive and up-to-date list.
[**] Data shamelessly stolen from http://www.kitz.co.uk - please see HERE for current on-line version.
EDIT
Same 4oD programme as earlier playing between 2157 and 2203 tonight. All queued data was apparently released and normal(ish) transfer rates resumed at EXACTLY 2200 hours.
The following graph documents data transfer when playing a random 4oD programme between 1857 and 1903 hours tonight:
As can clearly be seen, the data transfer rate was instantly reduced to sub dial-up speeds at EXACTLY 1900 hours. However, there does not appear to be anything of any relevance that corresponds to either the timing of this event or the effect of this event documented in the portal help pages for traffic management on my A/C. In fact it doesn't really appear to correspond to any documented rate limit for any service on any A/C type. So, I think some definitive explanation of exactly what traffic management PN are actually doing is required:
(1) Please confirm that the following table [**] allegedly documenting traffic management/shaping for my A/C type is entirely correct or advise on any relevant corrections and/or any additional traffic categories that there may be:
(2) Please define exactly what constitutes a "download site" and list all relevant domains/IPs that currently fall into this category or provide a link to a fully comprehensive and up-to-date list.
(3) Please define exactly what constitutes a "download server" and list all relevant domains/IPs that currently fall into this category or provide a link to a fully comprehensive and up-to-date list.
[**] Data shamelessly stolen from http://www.kitz.co.uk - please see HERE for current on-line version.
EDIT
Same 4oD programme as earlier playing between 2157 and 2203 tonight. All queued data was apparently released and normal(ish) transfer rates resumed at EXACTLY 2200 hours.
TBH, I don't much care which table is referred to just so long as PN provides definitive and up-to-date information on exactly what they're doing. The kitz page is obviously the most useful one but as you noted, the kitz and PN pages currently differ in specific details which I'm fairly sure never used to be the case. I just want to know which (if any) page is 100% correct and have definitive information on the various websites or 3rd party hosts that PN also choose to quietly throttle or intentionally introduce often unacceptable packet loss on. The data currently shown on the PN pages is far from unambiguous, by their own admission is not definitive and is more than likely several years old in any case I would imagine. The data on the kitz page is also no doubt long out-of-date but at least it always used to reflect reality in my experience.
With regards to the specific fault being discussed, there is nothing I can see on any account type that is defined to take the effect being seen between 1900 and 2200 hours. On the last documented occasion this problem cropped up it was between 1600 and 2300 hours. I think that I've also seen it occurring between 2000 and 2300 hours in the past as well and I've definitely seen additional problems due to PN DNS errors and/or inconsistencies preventing access to these services as well. This would appear to completely rule out any suggestion that Akamai RTMP traffic is being mistakenly classified as [insert some other traffic type here] and treated accordingly. In fact it tends to suggest that there is either a much more fundamental problem or that PN are intentionally tweaking undocumented things on the quiet in the hope that no one notices but have been caught in the act. I just wish that when PN go on what appears to be another one of their "robbing Peter to pay Paul" stylee missions that they'd remember that not only is my name Mike but I've got b*gger all left that's worth stealing in any case
Quite why this problem is primarily if not exclusively affecting MY account is absolutely anyone's guess but it's long since got past the point where it feels personal
What is totally clear however is that whenever there is the often used "very small number of customers affected" it would seem that I'm always one of them !!! If and when the current incarnation of this problem is fixed, it will probably mean that I have been unable to stream media during peak hours for around 1 month out of the last 8 where I have wanted to do so. In addition to this, I'm noticing more and more of the quite normal and totally innocent websites I regularly use often start becoming almost unusable during peak hours presumably because PN quite intentionally clobber traffic from certain 3rd party sources regardless of specific content and regardless of what effect those restrictions might have on the various websites trying to load. It's completely beyond me how PN can actually claim interactive web browsing is unrestricted and/or uncapped when it would appear that they routinely place often unreasonable restrictions on traffic from a variety of largely undefined sources despite not knowing what the data actually is, what it's being used for, which website it is associated with or what specific data rate is actually required in order for the site in question to work as intended. None of this comes close to constituting a particularly good service under any circumstances but esp not when I'm paying a premium at £22/m for what amounts to a 13Gb allowance due to my gross stupidity for tying myself way too firmly into PN many years ago
... wanders off looking forward to 'enjoying' another 3 or more days of no streaming media during peak hours
With regards to the specific fault being discussed, there is nothing I can see on any account type that is defined to take the effect being seen between 1900 and 2200 hours. On the last documented occasion this problem cropped up it was between 1600 and 2300 hours. I think that I've also seen it occurring between 2000 and 2300 hours in the past as well and I've definitely seen additional problems due to PN DNS errors and/or inconsistencies preventing access to these services as well. This would appear to completely rule out any suggestion that Akamai RTMP traffic is being mistakenly classified as [insert some other traffic type here] and treated accordingly. In fact it tends to suggest that there is either a much more fundamental problem or that PN are intentionally tweaking undocumented things on the quiet in the hope that no one notices but have been caught in the act. I just wish that when PN go on what appears to be another one of their "robbing Peter to pay Paul" stylee missions that they'd remember that not only is my name Mike but I've got b*gger all left that's worth stealing in any case
Quite why this problem is primarily if not exclusively affecting MY account is absolutely anyone's guess but it's long since got past the point where it feels personal
What is totally clear however is that whenever there is the often used "very small number of customers affected" it would seem that I'm always one of them !!! If and when the current incarnation of this problem is fixed, it will probably mean that I have been unable to stream media during peak hours for around 1 month out of the last 8 where I have wanted to do so. In addition to this, I'm noticing more and more of the quite normal and totally innocent websites I regularly use often start becoming almost unusable during peak hours presumably because PN quite intentionally clobber traffic from certain 3rd party sources regardless of specific content and regardless of what effect those restrictions might have on the various websites trying to load. It's completely beyond me how PN can actually claim interactive web browsing is unrestricted and/or uncapped when it would appear that they routinely place often unreasonable restrictions on traffic from a variety of largely undefined sources despite not knowing what the data actually is, what it's being used for, which website it is associated with or what specific data rate is actually required in order for the site in question to work as intended. None of this comes close to constituting a particularly good service under any circumstances but esp not when I'm paying a premium at £22/m for what amounts to a 13Gb allowance due to my gross stupidity for tying myself way too firmly into PN many years ago ... wanders off looking forward to 'enjoying' another 3 or more days of no streaming media during peak hours
I don't suffer the same issues as you, but I do watch your reports quite closely. Things do seem bizarre sometimes, and I can understand why you feel picked-on!
This is almost certainly caused by various websites making their own decision to offload some of their content onto a CDN - the primary reason for doing so to be able to get their data to users faster. That is, they choose to pay more for a service meant to improve the end-user experience by allowing pages to download faster. The CDN is, effectively, a geographically-spread cache.
Unfortunately, PN like to classify CDNs as a "Download Server", and cripple their speed - in some cases drastically. It totally undoes the intent that the website owners had in putting the content onto the CDN.
PN's classification, and use of traffic management, may have worked to the benefit of everyone when the CDN hosted large files meant for slow download. But nowadays, websites use them to host many shared files - including the basic graphics of a website, or the common Javascript files downloaded as part of every page. In these cases, the application of the most draconian limits is not beneifical to an ordinary browsing experience.
Having said that, I've just looked through the product archive, and the limits applied to "download servers" seems rather higher than the last time I looked - most seem to be 2Mbps now, when I recal speeds going as low as 512Kbps. I wonder if PN have upped the "Download Server" allowance for just this reason. It might explain why the Kitz data (which says it was last updated in 2009) shows lower speeds.
Is this true PN? Have you been changin the speed allowances on some of the archived products?
Time to change package? Or is there a reason for sticking to the Premier?
Quote from: mikeb In addition to this, I'm noticing more and more of the quite normal and totally innocent websites I regularly use often start becoming almost unusable during peak hours presumably because PN quite intentionally clobber traffic from certain 3rd party sources regardless of specific content and regardless of what effect those restrictions might have on the various websites trying to load. It's completely beyond me how PN can actually claim interactive web browsing is unrestricted and/or uncapped when it would appear that they routinely place often unreasonable restrictions on traffic from a variety of largely undefined sources despite not knowing what the data actually is, what it's being used for, which website it is associated with or what specific data rate is actually required in order for the site in question to work as intended.
This is almost certainly caused by various websites making their own decision to offload some of their content onto a CDN - the primary reason for doing so to be able to get their data to users faster. That is, they choose to pay more for a service meant to improve the end-user experience by allowing pages to download faster. The CDN is, effectively, a geographically-spread cache.
Unfortunately, PN like to classify CDNs as a "Download Server", and cripple their speed - in some cases drastically. It totally undoes the intent that the website owners had in putting the content onto the CDN.
PN's classification, and use of traffic management, may have worked to the benefit of everyone when the CDN hosted large files meant for slow download. But nowadays, websites use them to host many shared files - including the basic graphics of a website, or the common Javascript files downloaded as part of every page. In these cases, the application of the most draconian limits is not beneifical to an ordinary browsing experience.
Having said that, I've just looked through the product archive, and the limits applied to "download servers" seems rather higher than the last time I looked - most seem to be 2Mbps now, when I recal speeds going as low as 512Kbps. I wonder if PN have upped the "Download Server" allowance for just this reason. It might explain why the Kitz data (which says it was last updated in 2009) shows lower speeds.
Is this true PN? Have you been changin the speed allowances on some of the archived products?
Quote None of this comes close to constituting a particularly good service under any circumstances but esp not when I'm paying a premium at £22/m for what amounts to a 13Gb allowance due to my gross stupidity for tying myself way too firmly into PN many years ago
Time to change package? Or is there a reason for sticking to the Premier?
Is this relevant?
Quote from: Roswellgrey On the whole my netflix streaming has been pretty solid, but I have had a couple of instances where it ground to a halt, or suddenly dropped to a very low quality level.
When this happened last night, I tried to run up 5OnDemand (never use it normally) to see if that suffered from the same download speed problem.
Surprisingly, this wouldn't stream reliably at all - totally jerky and totally unwatchable
I fully appreciate that there are many reasons that could cause this, but to eliminate the obvious I thought I would run up wireshark this morning for a
quick test just to see what prioritisation was being applied to the various sources.
Source Differentiated Services Field BBC Iplayer 0x60 Netflix 0x80 4OD 0x80 5OnDemand 0x20 ITV Player 0x20
Results were as anticipated for BBC, Netflix and 4OD, but surely the 5OD and ITV Player shouldn't be classified as Bronze ?
If the same prioritisation was in place last night (2145 ish) with a busy network , it rather explains why 5OD was totally unusable ...
During some times of day/night (e.g. the middle of the night), the traffic is sometimes being classified as $80 (gold, interactive)
At other times of day/night (i.e. most of the time), the traffic is mostly being classified as $20 (bronze, non-interactive)
However, at some times of the day/night it seems pretty random which classification is given to traffic even when from the same IP address. The data for some programme segments or Ad breaks is classified as $80 whereas data for other programme segments or Ad breaks is classified as $20 even when the source IP and data type are exactly the same.
Just to make things even more interesting, Channel4 also now appear to be once again frequently swapping between a variety of data sources (Akamai, Limelight) and data formats (HTTP, HTTPS, RTMP) seemingly at random. HOWEVER, the same classification problems generally seem to exist no matter what the specific source or type of data - sometimes it's $80 sometimes it's $20 with no particularly obvious reason why. Up until Saturday the data had been quite consistently various Akamai IPs serving RTMP format data but I've seen all the other permutations at one point or another over the last 24 hours or so ... and most are classified incorrectly most of the time.
In addition to the classification issue, at some times of the day the traffic is heavily rate-limited (e.g. between 1900 and 2200 as previously demonstrated) whilst at other times of the day/night it is just randomly slowed down, interrupted or generally turned into an unacceptably erratic data stream causing jitters, pauses and general hiccups when trying to view the video.
None of the time periods during which different data classifications are being used corresponds in any way to those which are relevant for my A/C type. Similarly, none of the time periods during which various restrictions to the data stream are being applied corresponds in any way to those which are relevant for my A/C type. Traffic classification is at best inconsistent and at worst fundamentally and permanently wrong for certain sources.
In short it would appear to be a complete bl**dy mess and 100% non-compliant with what PN claim to be doing just like it was back in May last year. It's way more good luck than good management that this streaming media works at any time of the day/night and performance has been primarily dependant on just how much thousands of other users are using/abusing their connection. I would also very strongly suspect that it's been much like this for a long time (since May last year at the very least) although it is only just recently that a particular combination of PN errors has once again coincided with a high level of load from other users to make the problem very much more visible and slightly easier to quantify.
Although it's difficult to be certain due to other recent PN problems meaning usage data was unavailable in near real-time last week and has now apparently been lost completely, this streaming traffic would often appear to be being logged as P2P although almost certainly not always. Despite the obvious holes in my usage data records, I have allegedly used around 2GB of P2P so far this month ... despite having NEVER used anything that could even remotely be described as P2P in my entire life !!!
It's kinda hard to think of any way that this ridiculous situation could be more c*cked up than it apparently is ... but that's not intended to be a challenge so there's absolutely no need for PN to try and make things worse than they already are
I'm pleased (so to speak) to see that finally someone else has found severe problems with streaming media and is saying much the same as I have been. Because server IP and data type are dynamically assigned at time of use it is virtually impossible to provide definitive information from a specific connection. Different users will be getting quite different results depending on the particular data requested, their IP/location, host server load and general network load etc. In addition to this the capture files will be absolutely humongous in any case. If PN really need this data then surely they are able to set up test accounts with all the relevant configurations and check things out to their own satisfaction themselves. In fact I can't really believe that they don't have such A/Cs set up and in frequent use anyway not just for general testing but to verify customer reports of problems various. It is pretty crazy and somewhat unreasonable to say the least to expect customers to do all the fault -finding themselves in any case but especially so in this instance because there are quite simply way to many permutations to take into account and because of the dynamic nature of host and data type allocation for any specific attempt.
Having said all that, the problem previously demonstrated between 1900 and 2200 hours was conspicuous by it's absence last night but that it no way means the problem has been sorted. Data classification was still all over the place most of the day/night and unacceptable performance was still seen at random times, even during off-peak hours presumably due to having to share limited BW with the "download brigade" using/abusing their connection with massive amounts of P2P. Random but persistent unacceptable performance on BBC iPlayer was also noted at times during the evening.
At other times of day/night (i.e. most of the time), the traffic is mostly being classified as $20 (bronze, non-interactive)
However, at some times of the day/night it seems pretty random which classification is given to traffic even when from the same IP address. The data for some programme segments or Ad breaks is classified as $80 whereas data for other programme segments or Ad breaks is classified as $20 even when the source IP and data type are exactly the same.
Just to make things even more interesting, Channel4 also now appear to be once again frequently swapping between a variety of data sources (Akamai, Limelight) and data formats (HTTP, HTTPS, RTMP) seemingly at random. HOWEVER, the same classification problems generally seem to exist no matter what the specific source or type of data - sometimes it's $80 sometimes it's $20 with no particularly obvious reason why. Up until Saturday the data had been quite consistently various Akamai IPs serving RTMP format data but I've seen all the other permutations at one point or another over the last 24 hours or so ... and most are classified incorrectly most of the time.
In addition to the classification issue, at some times of the day the traffic is heavily rate-limited (e.g. between 1900 and 2200 as previously demonstrated) whilst at other times of the day/night it is just randomly slowed down, interrupted or generally turned into an unacceptably erratic data stream causing jitters, pauses and general hiccups when trying to view the video.
None of the time periods during which different data classifications are being used corresponds in any way to those which are relevant for my A/C type. Similarly, none of the time periods during which various restrictions to the data stream are being applied corresponds in any way to those which are relevant for my A/C type. Traffic classification is at best inconsistent and at worst fundamentally and permanently wrong for certain sources.
In short it would appear to be a complete bl**dy mess and 100% non-compliant with what PN claim to be doing just like it was back in May last year. It's way more good luck than good management that this streaming media works at any time of the day/night and performance has been primarily dependant on just how much thousands of other users are using/abusing their connection. I would also very strongly suspect that it's been much like this for a long time (since May last year at the very least) although it is only just recently that a particular combination of PN errors has once again coincided with a high level of load from other users to make the problem very much more visible and slightly easier to quantify.
Although it's difficult to be certain due to other recent PN problems meaning usage data was unavailable in near real-time last week and has now apparently been lost completely, this streaming traffic would often appear to be being logged as P2P although almost certainly not always. Despite the obvious holes in my usage data records, I have allegedly used around 2GB of P2P so far this month ... despite having NEVER used anything that could even remotely be described as P2P in my entire life !!!
It's kinda hard to think of any way that this ridiculous situation could be more c*cked up than it apparently is ... but that's not intended to be a challenge so there's absolutely no need for PN to try and make things worse than they already are
I'm pleased (so to speak) to see that finally someone else has found severe problems with streaming media and is saying much the same as I have been. Because server IP and data type are dynamically assigned at time of use it is virtually impossible to provide definitive information from a specific connection. Different users will be getting quite different results depending on the particular data requested, their IP/location, host server load and general network load etc. In addition to this the capture files will be absolutely humongous in any case. If PN really need this data then surely they are able to set up test accounts with all the relevant configurations and check things out to their own satisfaction themselves. In fact I can't really believe that they don't have such A/Cs set up and in frequent use anyway not just for general testing but to verify customer reports of problems various. It is pretty crazy and somewhat unreasonable to say the least to expect customers to do all the fault -finding themselves in any case but especially so in this instance because there are quite simply way to many permutations to take into account and because of the dynamic nature of host and data type allocation for any specific attempt.
Having said all that, the problem previously demonstrated between 1900 and 2200 hours was conspicuous by it's absence last night but that it no way means the problem has been sorted. Data classification was still all over the place most of the day/night and unacceptable performance was still seen at random times, even during off-peak hours presumably due to having to share limited BW with the "download brigade" using/abusing their connection with massive amounts of P2P. Random but persistent unacceptable performance on BBC iPlayer was also noted at times during the evening.
