Poor data transfer rate in general, streaming issues in particular

[#1]

Hi ejs,
Indeed, this confirms the same issue and does contain a significant volume of data prior to the first 0x60 packet. The first flow is odd, as it opens a connection and just closes it, though the very next one to BBC News does also get flagged as 0x60.
Ejs, how easy was that to replicate?
We can see it is 3 mins into the start of the capture, but we can't see if the lengths you had to go to to replicate it.
I really hope it is easy for you to replicate, as we would like to co-ordinate a time for you to do this that we can also look at some internal details at the time.
Let us know, as we will let you know more depending on the response.

[#2]

It was easy to replicate, there was no setup involved besides clearing seamonkey's cache.
It appears to be live TV that tends to use HTTP streaming. I think I had http pipelining enabled for yesterday's, I just captured another one now with pipelining turned off, the stream came from limelight networks but it was also flagged 0x60. I'm on the Unlimited account, but I think that should still have streaming as one class and content distribution networks as another, lower category.
http://ejs1920.users.sourceforge.net/bbc-streaming-20120601.pcap

[#3]

I decided to have another look after having to re-connect, and ending up on one of the "good" pcl gateways this time.
The live BBC news stream this time got flagged 0x80
http://ejs1920.users.sourceforge.net/bbc-streaming-20120603-akamai-0x80.pcap
Blocking port 1935, live BBC 1 http stream from totally different akamai IP block, flagged 0x60
http://ejs1920.users.sourceforge.net/bbc-streaming-20120603-akamai-0x60.pcap

[#4]

Thanks for the detail.
I'm going to grab some time to review those shortly and see if we can replicate this now that there are a few indicators to allow us to do so. It does seem that this may be down to the type of activity performed which we were not doing.
Wont be quick as whilst  bank holidays allow us all time to relax, you are always a day (two in this case) down following.
Mikeb,
Based on the detail from ejs, can you indicate if you were using live streams rather than iPlayer 7 day content? (or at least a mix of it).

[#5]

Just a quick update for you all.
After fighting with the reliability to block port 1935, we have now started a number of captures. All so far correctly mark the data, but we have a few known test scenarios to replicate first so we can correctly mimic your own accounts in the network.
So far, we are still not seeing 0x60 packets, but this is only in the early stages.
One thing to note ejs, I cannot see port 1935 being blocked in your captures.
You note that you can force 0x60 through blocking this and whilst I note the lack of traffic to that destination port in the last of the captures, it does indicate the capture was started after you initiated the block (there are no SYN requests to port 1935).
This has the effect that we can't see enough of the earlier data showing it going from good to bad (so to speak).
Hopefully once we have the correct configuration on our test account, we will be able to readily replicate that.
As a side note, is your router/firewall silently discarding the SYN requests to port 1935, or responding with an appropriate ICMP packet?
Our tests on our TG582n result in a ICMP stating administratively disabled, which is expected. Though I'm interested to see what is in place in your tests (which as above, the captures don't show).

[#6]

The port 1935 blocking was done by using the iptables command for rtmpsuck (from rtmpdump), but not running rtmpsuck. Used because it's usually on hand to copy and paste.
The iptables command is:
iptables -t nat -A OUTPUT -p tcp --dport 1935 -m owner --uid-owner ejs -j REDIRECT
This redirects outbound traffic on port 1935 to localhost. The capture was only recording wlan0, so the redirected SYN packets (and DNS traffic to/from the local DNS cache server) aren't shown. Without rtmpsuck running, there's nothing to receive the redirected traffic, so it just gets a tcp RST in reply.
I've just taken another capture, on all interfaces, but the streaming was only correctly tagged 0x80 packets from Limelight.

[#7]

Here's another capture (23MB):
http://ejs1920.users.sourceforge.net/bbc-streaming-20120611-evening.zip

• HTTP streaming forced with a more straightforward command: iptables -I OUTPUT 1 -p tcp --dport 1935 -j REJECT


• Capture was recording on all interfaces

I noticed a few early packets flagged 0x60, but I think only the last stream (live football on BBC 1) was marked 0x60, there are a few preceding streams correctly marked 0x80.

[#8]

Thanks, explains the lack of SYNs.
That new capture helps a lot and should allow us to complete the picture in order to replicate, but adds a little complication as our blocking isn't triggering unreachable responses, but administratively blocked ones. This shouldn't be an issue, but may be a factor if the two connection rejections are handled in different ways client side (it's not handled differently on Plusnet side, as we don't see the packets in either instance).
Just need to spend a little time cross referencing now.

[#9]

I've looked at this post a couple of times over the past few weeks because my plusnet streaming is almost unwatchable. I've seen the dialogue between mikeb, P Richardson jelv et al .
I have to agree with jelv - I'm not going to start a whole load of diagnostics; I'd just like someone to explain to me why streaming a program on 4OD and iplayer is so BAD ? I never had any trouble like this when I was with Virgin. I did a bandwidth speedtest at 9pm. However this message popped up after I'd done it: [Sorry - My Broadband Speed is currently experiencing technical difficulty and may display misleading test results. Thanks for bearing with us while we fix things.]  - so I don't even know if the results it gave were accurate.
Anyway, the reported result showed 914 kB/s.  download speed It was reading 3.01 MB/s when I tested it at 8.20pm. I was attempting to watch something on 4OD at the time but speech & picture were badly out of synch: picture stuttering, stammering pausing & sound / speech deciding to do its thing as & when it pleased. Ironically the speech flowed continuously if I had a different tab open but as soon as I clicked back on to 4OD it went back to its old ways. Is there something I'm missing here?
Is there a simple explanation for this cos I ain't gonna be waitin til midnight before I start watching my shows?
Thank you. 

[#10]

That does sound as if it might be exchange contention. Have you checked your exchange status?

[#11]

Hi jelv,
Thanks for the link; here's what I got:
Exchange Status Checker
Results: Cambusnethan

Code: WSCAB
County: Strathclyde
Enabled: 08 Dec 2004
Market: 3
Colour: Green VP capacity at this exchange is currently showing as Green.
Click here for further details
Colour: Green BT have advised that this exchange is enabled for WBC on 21CN
Colour: Unknown You can view recent Service Outages for this exchange here
Colour: Unknown BT has published DSL Max upgrade information for this exchange
Click here for further details
on the VP...
Results: Cambusnethan

Code: WSCAB
County: Strathclyde
Enabled: 08 Dec 2004
Market: 3
green Virtual paths: Green
There are currently no known capacity problems on your exchange. There may still be an exchange problem, however BT are not currently reporting that they are aware of it. Please contact Support if you are having speed problems, who can advise further.
Record last updated: 01 Jun 12
Historical information for this exchange:
Status Date
green 25 Apr 12
green 11 Mar 12
green 15 Jan 12
green 14 Dec 11
green 05 Nov 11
Please note: This checker is not a generic fault tracker. It is updated weekly when updates are available and reflects a snapshot of speed capacity from each exchange. Results shown here should not lead you to conclusive proof of an issue.
Does that help in any way?
 

[#12]

That indicates that the exchange is OK (although I note that Plusnet are being tardy about updating the checker yet again  )
You need to run the BT speedtest when it is going slow and then raise a fault: http://faults.plus.net/