4 ms·

> Their testing methods were very imprecise. I agree. The article states that a custom web server was used, but the web server has no means of tracking protoco

• jsnell 15y ago
  A sufficiently custom web server does have the means to estimate protocol level overhead (TCP and IP headers, retransmissions). The only reason it couldn't track would some kind of a system that splits TCP connections (e.g. a proxy) located somewhere between the billing system and the web server. But most forced proxies only run on port 80, and could easily be circumvented. The measurement would not be totally accurate as the sender couldn't know at which point packet loss happened. A packet lost somewhere after the billing system and retransmitted should count, a packet lost before the billing system should not. But it would at least give an upper bound. If the bottleneck in the system is the RAN rather than the internet links that upper bound could actually be quite close to the real figure. Of course some technical competence would have been required for this experiment, probably more than these clowns have. And it would likely have shown about 5-10% protocol overhead, which would not have done their case any good.