September/October 2019 issue of acmqueue The September/October 2019 issue of acmqueue is out now

Subscribers and ACM Professional members login here


  Download PDF version of this article PDF

Error 526 Ray ID: 53449a93097ee758 • 2019-11-12 01:06:31 UTC

Invalid SSL certificate








What happened?

The origin web server does not have a valid SSL certificate.

What can I do?

If you're a visitor of this website:

Please try again in a few minutes.

If you're the owner of this website:

The SSL certificate presented by the server did not pass validation. This could indicate an expired SSL certificate or a certificate that does not include the requested domain name. Please contact your hosting provider to ensure that an up-to-date and valid SSL certificate issued by a Certificate Authority is configured for this domain name on the origin server. Additional troubleshooting information here.


Originally published in Queue vol. 11, no. 8
see this item in the ACM Digital Library



Aleksander Kuzmanovic - Net Neutrality: Unexpected Solution to Blockchain Scaling
Cloud-delivery networks could dramatically improve blockchains' scalability, but clouds must be provably neutral first.

Jim Waldo - A Hitchhiker's Guide to the Blockchain Universe
Blockchain remains a mystery, despite its growing acceptance.

Yonatan Sompolinsky, Aviv Zohar - Bitcoin's Underlying Incentives
The unseen economic forces that govern the Bitcoin protocol

Antony Alappatt - Network Applications Are Interactive
The network era requires new models, with interactions instead of algorithms.


(newest first)

Anupama | Thu, 03 Jul 2014 07:48:11 UTC

Hello Sir,

Thank You so much for such an amazing document on TCPtrace and RTT. Its one of my best sources to learn about RTT.

As I am currently working on it, came across a situation in which I need to calculate RTT in microseconds.It would be really great if you could clear my doubt on this.

So Is there a way to change the precision of RTT in tcptrace? If so, how is it possible?

Olivier Bonaventure | Tue, 29 Oct 2013 13:51:29 UTC

Getting the ground truth about delay measurements in today's Internet is difficult. In a real network, many factors influence the measured delay. One of these factors is the utilization of load-balancing techniques such as Equal Cost Multipath (ECMP) to spread the load on routers among different paths.

Most deployments of ECMP rely on a hash function computed on the source and destination addresses and the source and destination ports of the packet. When there are several equal cost paths to the same destination, the routers will load balance the packets over these paths by ensuring that all packets from a given TCP connection follow the same path. When these routers process ICMP packets generated by ping, the load-balancing algorithm does not work in the same way and successive ping packets may follow different paths through the network. Some of these paths may have very different delays.

If you plan to perform delay measurements with ping, I'd encourage you to read the paper "From Paris to Tokyo: On the Suitability of ping to Measure Latency " written by Cristel Pelsser, Luca Cittadini, Stefano Vissicchio and Randy Bush and presented last week and the Internet Measurements Conference. It highlight several important difficulties when using ping to measure delays.

Leave this field empty

Post a Comment:

© 2019 ACM, Inc. All Rights Reserved.