While testing the maximum transmission speed of my category 6 HSDPA terminal (Motorola V3xx, theoretical maximum of 3.6 MBit/s) I found out that Vodafone Italy is applying traffic shaping to file downloads to slow them down. Dear Vodafone, are you sure this is really necessary?
Each TCP connection seems to be limited to a speed of around 700 kbit/s. It sounds like a lot but nowhere near enough to test the maximum downlink speed of the connection. Only when downloading three files in parallel did I reach the ceiling of around 2 MBit/s with average network reception levels. Have a look at the picture on the right which shows how the accumulated transmission speed increases with 1, 2 and 3 simultaneous file downloads.
To make sure it was not a limitation on the server side I downloaded files from different servers. Also, I compared the download speed in the network of TIM where a single file download was enough to push download speed to over 1.4 MBit/s (with a category 12 terminal, theoretical maximum speed of 1.8 MBit/s).
Also I noted lots of TCP packet losses on the Vodafone Italy network during the day and in the evening while during the morning everything was all right. Strangely enough performance of the network was o.k. when I used a roaming SIM card from Vodafone Germany just minutes later. In this case the GGSN in Germany is used rather than a GGSN in Italy. Looks like they’ve got a huge bottleneck in that corner.
Looks like TIM will keep me as a customer when I am in Italy, their performance has been flawless over weeks.
Interesting. Looking at a closeup of your NetMeter graphic, it seems to me that the unit of measure on the Y axis is KBytes per second. Is this the case, or is it in Kbits per second?
Anyway, I am surprised that just because you measured an upper limit on TCP throughput, you come to the conclusion that the operator is applying traffic shaping procedures in the network – implying that the operator is deliberately slowing your traffic down.
Apologies if I’ve missed something but won’t the bandwidth delay product influence the performance of TCP connections? Specifically, the limitations that round trip time (RTT)- has on the throughput achievable by a TCP processor. Ignoring the effect of bit errors (which are usually quite low after cellular radio FECN mechanisms have done their work) the bandwidth delay product quite simply states that in an unmodified (standard) TCP implementation, your maximum throughput in kbytes/s on any particular TCP connection is your maximum receive window size (RWIN) divided by the round trip time in milliseconds.
Therefore kbps = 8*RWIN(in bytes)/RTT(in ms)
Let’s assume that the one-way latency on your HSDPA is around 300ms (just a guess) then the maximum theoretical TCP throughput you could expect to see is 524280/400. (524280 is 8*65535 which is the maximum TCP window size, and 600 is twice the 200ms latency). This equals about 873kbps, which is in the order of magnitude that you are reporting.
The moral of the story is that latency of your connection will place an upper limit on TCP connection throughput that can be much lower than the available capacity. Is that what you are experiencing perhaps – as an alternative to the operator traffic shaping theory?
Sorry – in the maths above you will have spotted I wrote 400 instead of 600, that was a typing mistake – the end result is correct.
Hi Jag,
Thanks for your comment! Your formula of the bandwidth delay product is correct but the delay you assumed is much too high. The round trip delay time to the host from which I downloaded the files was not 600 ms but rather only 180 ms. Thus, with a window size of 65535 bytes which you assumed correctly the maximum TCP transmission speed would be:
((65535 bytes * 8 bits) / 0.18 s) = 2.9 MBit/s.
(instead of 873 kbit/s with the 600ms you assumed).
I’ve blogged about this before, take a look here: http://tinyurl.com/2wgxma
Even with all the maths around it I might have been reluctant to state that Vodafone Italy does traffic shaping if I only had the maths to prove it. However, downloading the same file via the Telecom Italy HSDPA network with the same setup resulted in a much higher speed. Also in TIM’s network downloading several files simultaneously had no effect on the overall download speed as in the Vodafone test described above.
So I remain with my statement that Vodafone Italy seems to apply traffic shaping.
Cheers,
Martin
Thanks for the reply Martin, and especially teh clarification of RTT. So, the only other thing to eliminate is packet loss conditions (errors), and application protocol behaviour that could be preventing TCP window from opening to the max. Any thoughts on this – for example what protocol were you using for the file transfer? Was it FTP? Or was it a HTTP-based file transfer. FTP will tend to let TCP ramp up to max window, but I’m not sure about HTTP. The reason why I’m skeptical about traffic shaping is because operators are generally not that clever! 🙂
Hi Jag,
I pretty much went down the same path as you did in your replies and can rule out the things you mention as well. Here we go:
Packet loss (errors): I have Wireshark traces of pretty much all tests I ran so I was able to verify this. At the time I ran the multiple file download test there was almost no packet loss. So I can rule this out as the cause. Side note: As mentioned in the original post, the Vodafone Italy network suffered from heavy packet loss during a number of tests I made during afternoon and evening hours. During these times, throughput was horrible due to frequent retransmissions and TCP window ramp up.
Transfer format (HTTP or FTP): All file download test were performed with HTTP. As the file download performance of the same file over the TIM HSDPA network was fine and reached the limit of the channel and as the transport network does not influence the TCP window ramp up I can rule out this as a cause as well. As transferring several files simultaneously increase the overall throughput I can also rule out cell traffic of other users as the cause.
“Operators are usually not that clever”: Good point, but since I have proof that things work up to the limit in the TIM network and also in the German Vodafone Germany I can’t really see any other reason for the cap than active throttling.
Cheers,
Martin
Hi there! I am currently performing HSDPA test and I hope that someone can point me to the correct direction.
I have set the followings:
1. HS-PDSCH codes to 10
2. HS-SCCH codes to 2
3. 5 E1s
With the configuration above and by using a CAT 8 UE I am suppose to get a throughput of 7.2Mbps. However I only get a maximum of 2.2Mbps. Is there a limitation at the server of at the core network? How do I check?
I would appreciate someone could assist me on this.
Thank you.
May you be well and happy.
Tee