I disagree with your assumption that video==!educational.
There are lots of educational videos online. In Denmark we even have the public libraries offering a special section of their online video libary designed for use by schools.

Generally, there are two separate reasons for blocking content:
1. Policy. You block access to inappropriate content for "political" reasons. In this context, "political" means corporate policy, parents, politicians or someone else in charge dictates which content is inappropriate.
2. Bandwidth. You block access to some content, hoping to solve bandwidth issues. This rarely works. Instead of blocking some content, you should ensure that all people have access to a fair share of the bandwidth, by User Load Balancing(TM) or similar. Besides, company policies should be dictated by company management, not by the IT department.

The original poster is clearly in the Policy reason for blocking content. I wouldn't recommend bandwidth throttling if that is not the issue.

And as ericartman writes in his post below, at any school the kids are bright enough to find a way around the filter (or ask the one kid who was bright enough to find the way around the filter).

At the high level statistical point of view, you are absolutely correct - this is the "steady state" TCP was designed for. However, modern NICs use Interrupt Coalesce and similar techniques to reduce the CPU load, and this causes burstiness when looking at the traffic at the microscopic level.

Not always true. Some of our resellers even have customers running VoIP on satellite links.

We have resellers in many countries, and sure you can buy QoS as a value added service on your MPLS line from any decent telco, but none of the ISPs I have ever heard of provide QoS on ordinary public internet ADSL lines. If you can point me towards just one ISP that advertises DiffServ or similar tag based QoS on their public internet ADSL lines, I will be happy to correct my statement from "ISP's don't use QoS to prioritize RTP traffic..." to "Most ISP's don't use QoS to prioritize RTP traffic...".

Agreed!

Mostly true, except there are alternatives to classic QoS (i.e. tag based QoS) that do allow you to use latency sensitive applications over (comparatively) low bandwidth connections. But if protocol designers at Google (and elsewhere) work under the assumption you just described (roughly paraphrased: "latency sensitive applications do not belong in non-QoS networks") we can all wave goodbye to Skype, GoToMeeting, WebEx and a lot of other realtime collaboration tools that use the plain internet as transport medium! I originally commented this story to warn against turning the most popular protocol on the internet (HTTP) in that direction.

Yes, I absolutely and completely agree that jitter and latency is key to the user experience!

TwobyTwo answered with the reference below before my answer here, so I won't repeat that. I will address your question about the router breaking up the TCP flow in MTU sized chunks.

Yes, the TCP connection is sent in packets of MTU size, but they are all queued up in a single queue in the ISP's router. And because the packets are sent in bursts (proportional to the window size) they are stored in the router in chunks with all the packets of a burst in each chunk.

Packets are sent in bursts, so increasing the burst size from 3 to 10 packets of 1500 octets gives you a burst of 15000 instead of 4500 octets. You are absolutely right that when using a QoS mechanism to prioritize the VoIP over the Web traffic the SPDY increased window size doesn't affect the sound quality. However, ISP's don't use QoS to prioritize RTP traffic on your public internet ADSL connection.

I was just trying to point out that they are optimizing their own application performance at the cost of performance for other applications.

I am the CTO of a company developing bandwidth and latency optimization products (http://www.smartsharesystems.com/), and we have lots of customers that will confirm that latency and jitter were reduced to acceptable levels when they installed our product. If you do it right, it is effective.

-Morten Brørup
CTO, SmartShare Systems

SPDY is a great example of someone thinking only of their own application.

By increasing the initial window size from 3 to 10 they add to the bufferbloat effect (at the microscopic level) and increase Jitter from tolerable 38 ms to intolerable 126 ms on a 1 Mbit/s ADSL line. This level of jitter severely affects VoIP sound quality. And for this calculation I have assumed that the web browser only uses one TCP connection to load the page; if it uses two TCP connections the Jitter may double.

But hey! What does any application developer care about other applications? They are only concerned about getting their own application sped up.

When you improve the performance of your application, you should think about how it degrades the performance of other applications. If someone recommended increasing the O/S priority level of the web browser to the maximum, so all your other applications slowed down to a halt while the web browser was running, you would probably object. The increased initial window size is a comparable recommendation, but at a network buffering level, so very few people understand its negative side effects.

We all want faster loading web pages, but we also want other applications to respond faster, and we also want perfect VoIP sound quality without the walkie talkie effect caused by high latency or jitter.

A SmartShare on the main connection will give you a few nice things:
1. User Load Balancing - the 100 Mbit/s connection is shared evenly amongst the active users. No bandwidth waste and no unnecessary bandwidth limits. (No configuration required.)
2. Dynamic QoS - VoIP (including Skype) is prioritized over Data traffic. (No configuration required.)
3. Limit bandwidth for Peer-to-Peer users, so they don't swamp the wireless access points, and possibly even stop using their Peer-to-Peer application. (Optional.)
4. Redirect SMTP connections to the ISP's SMTP relay, so Outlook (and other email clients) still works when guests' laptops are configured for using the SMTP relay of their ISP at home.
5. Real-time and historical graphs showing how much bandwidth is available for each user, so you know what kind of bandwidth the guests actually have available, and when it's time to upgrade the internet connection.

Did I mention that I work for SmartShare Systems (http://www.smartsharesystems.com/), and that we sell lots of SmartShare boxes for hotels, dormitories, highschools etc. for this kind of network. And lots of smaller SmartShare boxes for small businesses using internet and cloud based services on low (or medium) bandwidth connections.