The third annual OneWebDay was yesterday. Here are videos and other links. : Thanks to everyone, everywhere, who got involved. Onward.
I was particularly moved by the email I got from New Zealand:: “What on earth have you unleashed?“: I cheered when a Rio de Janeiro newspaper gave OneWebday full-page focus. I was delighted to see an interview from Ghana drawing attention to inadequate connectivity. In New York, we had a wonderful session with several terrific speakers, and Prof. Lawrence Lessig in particular gave a strong call for using the internet to get us out of the mess we’re in.
In San Francisco, the City extended wireless access to 1000 more people in lower-income housing, and built three tech centers using refurbished computers. In Portland and Milwaukee and Austin there were major meetings – see the video and press coverage. I was so delighted to see the professionalism and impact of the DC group’s meeting, which got Commr. Jonathan Adelstein involved as well as several other elected officials.
There’s more news to come from OneWebDay. It’s taking on a life of its own, but it needs fulltime staff and adequate resources. Please contribute. We’ll start planning for next year – right away.
These disclosures deserve a level of attention similar to the reception given the 250 GB cap a little while ago.
For one thing, Comcast is certainly conceding that they have used reset packets in the past.
When the number of unidirectional upload sessions for any of the managed P2P protocols for a particular Sandvine PTS reaches the pre-determined session threshold, the Sandvine PTS issues instructions called Ã¢â‚¬Å“reset packetsÃ¢â‚¬Â that delay unidirectional uploads for that particular P2P protocol in the geographic area managed by that Sandvine PTS.
It’s also worth noting that Comcast is conceding that it is examining much more than header information. They’re using the (historic) OSI model to describe what they’re inspecting, and penetrating very deep into information about what users are looking at and what applications they’re using.
More importantly, though, it looks as if Comcast plans to use tiering quite actively. The company is saying that if its software decides that (1) a particular subscriber is using a “disproportionate” share of bandwidth, and (2) the relevant node is being used at 70% capacity (signalling approaching congestion), (3) that user will be dropped down to “lower priority” speeds. The company will decide when that user will be allowed back up to higher priority speeds.
So, if you were doing a video conference call provided by a non-Comcast vendor, and the call was using “too much” bandwidth, you could lose the call – it could become too jittery to be satisfactory. I understand that Comcast’s own voice product is not subject to this treatment. It’s not within Comcast’s defined term “Comcast High Speed Internet (HSI),” which it says is “[a] service/product offered by Comcast for delivering Internet service over a broadband connection.”
That’s not great for voice or videoconference products that aren’t provided by Comcast. It makes things quite unpredictable for them.