I think you may be missing the point of the tests. The test is not there to prove whether BitTorrent increases latency or not, and I have done a lot of that kind of analysis before for unrelated posts. The test here is done to refute Riley and Topolski’s claim that just the mere use of prioritization technology on some applications (IPTV in this case) causes extreme increases in jitter for other applications that are not prioritized.

Furthermore, nobody cares about percent difference in jitter and it is an irrelevant metric. If jitter was increased from 1 millisecond to 3 millisecond, that’s a 200% increase but no one cares about it. Moreover, this would actually be an increase of latency from 40 milliseconds to 42 milliseconds which would actually constitute a 5% increase in delay, an even the most hardcore gamer with extreme reaction times won’t notice that 2 millisecond change. See how we go from characterizing this as a 200% increase to a 5% increase and why this is statistic smoke and mirrors?

Furthermore, the exact increase in jitter in my example was an average of 0.3 millisecond and worse case increase of 1 millisecond. That’s explained by the mere existence of the IPTV packets. Of course it’s going to take a little extra time to forward those packets.

As Rich Clarke stated, you cannot rely on “eye-ball” analysis. The average jitter increase of 0.3 milliseconds is so low that no engineer should even bat an eye.

It is amazing to me that you do not even understand how insignificant 0.3 millisecond or even 1 millisecond is in the context of quality of service engineering. Anytime you run a lot of packets through a network, especially a significant percent of the link, the best result you can obtain is holding the increase in jitter to a millisecond or less because that is how long it takes to transmit a packet. That increase is not a result of use of prioritization, but the mere existence of the HD IPTV packets.

Also, I did not mis-characterize your statement.

You responded to my statement “Every FTTN deployment does in fact deploy DiffServ type prioritization on the IP network.” with “Can you give me some examples of such deployments? I’m not familiar with any.”

Now I don’t expect most people to know that, but someone who is trying to make policy arguments on these issues should know this. Perhaps you simply didn’t realize that AT&T U-verse technology was based on FTTN VDSL2 technology. That wouldn’t surprise me since you confused FTTN for FTTH when you made the following statement.

“putting voice and video on separate wavelengths is not the same thing as prioritization. So it’s not remotely accurate to say that “every FTTN” deployment prioritizes voice and video”

Chris, while there is a noticeable difference, it would be an acceptable difference compared to the suffrage endured while trying to utilize VoIP during a massive P2P download.

While I could be wrong, a little bit more data isn’t a bad thing.