Comments on: TCP: Without Local Content, UFB won’t be Ultra Fast https://nztelco.com/2011/06/03/tcp-without-local-content-ufb-wont-be-ultra-fast/ Sat, 04 Jun 2011 23:40:12 +0000 hourly 1 http://wordpress.com/ By: jonbrewer https://nztelco.com/2011/06/03/tcp-without-local-content-ufb-wont-be-ultra-fast/comment-page-1/#comment-22 Sat, 04 Jun 2011 23:40:12 +0000 http://nztelco.com/content/?p=247#comment-22 In reply to John Allen.

Hi John, thanks for your post.

Sometimes it’s not ISP throttling your connection. If you’re using the mobile service on both, you’ve got as much (if not more) contention in the last mile as you do on International circuits. You’ve also got the potential for immense latency compared to fixed lines. OFCOM in the UK have just this year found the average last-mile latency for mobile broadband services in the UK is 192ms.

For streaming media over TCP – like YouTube – this is the equivalent of moving an NZ local server to LA. A Windows XP user with average mobile broadband latency shouldn’t expect a single TCP stream of greater than 2.7mbps.

Latency and TCP window size is however just one problem with TCP over wireless. Packet loss and jitter (inter-packet delay variation) also give TCP a very hard time. Performance over wireless is enough of a problem that serious academic research is underway to find a fix. As demonstrated by the slow uptake of RFC1323 though, once a fix is out there, it can take a decade to get in to commercial operating systems.

Like

]]>
By: John Allen https://nztelco.com/2011/06/03/tcp-without-local-content-ufb-wont-be-ultra-fast/comment-page-1/#comment-21 Fri, 03 Jun 2011 22:01:42 +0000 http://nztelco.com/content/?p=247#comment-21 I understand what you are saying but am not competent to add anything technical to your discussion. My measure of speed is, using Youtube as an example, simply whether or not a video play back stutters.

When the streaming video downloads faster than I can watch it, all is fine. That is all that matters to me (when watching Youtube). When I have to wait for the buffering, then there is something inadequate in my connection.

When Youtube stutters, I have been known to fire up another computer, connect on a different ISP and compare the download times of the same clip over the two networks. It is interesting to note that one service can stutter (often taking 3 times longer to view the clip than the actual play time) and the other not.

I can see only one reason for this difference (I have tried to eliminate other variables): One of the two ISPs controls data throughput from this service.

If I use one of the ISPs broadband speedtest service, over a number of runs, I get consistent speeds, speeds that do not reflect the stuttering Youtube playback.

When I complain to the ISP that appears to be throttling data from Youtube, they of course deny any manipulation of the connection speed.

The two ISPs are Telecom Xtra and Vodafone. For each, I use their mobile service.

I believe that this is a bigger issue for our experience of ultra fast broadband than the TCP issues discussed above.

Does any one else experience apparent throttling from an ISP?

Like

]]>
By: jonbrewer https://nztelco.com/2011/06/03/tcp-without-local-content-ufb-wont-be-ultra-fast/comment-page-1/#comment-20 Fri, 03 Jun 2011 11:06:12 +0000 http://nztelco.com/content/?p=247#comment-20 In reply to Jamie.

The real hang-up is any media that streams over HTTP comes as a single TCP stream. Netflix, Youtube, Flash Video, iTunes, & Hulu all fall into this category – and they make up half of the content traversing the Internet in 2011.

Half the content that people want is coming down as a single TCP stream. Half the users out there are on Windows XP. This spells trouble for users in New Zealand – unless those single streams start originating a lot closer to the end users.

Like

]]>
By: Jamie https://nztelco.com/2011/06/03/tcp-without-local-content-ufb-wont-be-ultra-fast/comment-page-1/#comment-19 Fri, 03 Jun 2011 10:35:34 +0000 http://nztelco.com/content/?p=247#comment-19 Hi jon,

Some very valid comments made here. One other possible solution to deal the limits you describe are multithreaded applications. And let’s not forget that protocols like http1.1 are multithreaded. From memory googlemaps opens up around 300 tcp threads (or streams). Normal web applications today overcome the limits you describe by opening more than one TCP flow at the same time.

Now while this is a somewhat acceptable approach, goodness me TCP thread hungry apps rapidly kill IPv6 work arounds such as carrier grade nat.

So i guess that’s another reason to start supporting IPv6. A faster UFB 😉

Like

]]>