Milton Mueller vs. Dan Kaminsky on ISP Traffic Management Detection

   

Few days ago I had a post about Dan Kaminsky's claim to have a new tool that can tell if a certain ISP uses DPI and QoS polices to discriminate traffic flows, based on their content (Google vs. Bing, for example). See "Dan Kaminsky: I Can Tell if Your ISP Breaks Net Neutrality" - here. 

  

Replies to my tweet referring to the post, pointed me to an Internet Governance Project (IGP) post by Milton Mueller (picture), Professor, School of Information Studies, Syracuse University. The article -"The new Kaminsky bug (here)" bashes Dan's announcement (as his tool, n00ter, is not available yet) and the hype it created.

For background on Prof. Mueller activity see my previous posts: "NSF Funds Research on DPI" - here and "New Paper on "Deep Packet Inspection and Internet Governance" - here.

See also "FCC: We Need "Apps" to Monitor Naughty Service Providers" - here which is mentioned in the new post - is that the reason for all this?

Back to Mueller's post: "We found it really hard to get excited about this .. Kaminsky hasn't actually released his tool yet, .. there are at least half a dozen other tools out there already which do the same thing .. Check out Google's MeasurementLab site, for example. There's Glasnost  [see "Glasnost: These ISPs are Shaping Traffic!" - here] and ShaperProbe there .. Our research project on deep packet inspection (DPI) has used the data generated by Glasnost extensively"

" .. the idea of testing for minute differences in web site delivery speed shows that Kaminsky and other would-be net neutrality posses may be a couple of steps behind those cattle-rustling, black hat ISPs. What the more sophisticated ISPs are doing with DPI and traffic-shaping technologies is more focused on monetization than on speed discrimination"

Dan Kaminsky replied with the following tweets: 

• heh! The slides are at dankaminsky.com. The technique is pretty cool, and should give you good data
• the basic idea is to normalize the source and path of data from multiple IPs, down to the ISP
• if the same server and the same path give different qos for different identities, there's policy
• the problem with pure protocol tools is you have no baseline for performance. How fast should a stream be?
• by normalizing server and path, you know unbiased latency and drop rates for which to compare