Re:Clockwork raises $21M to keep server clocks in sync
by danzheng on Saturday March 19, 2022 @02:01PM
(#30736017)
I'm from the Clockwork team, thanks for listing the relevant papers.
Accurate clocks sync enables true one-way delay measurements (instead of RTT/2), this allows for edge-based network visibility. We launched Latency Sensei beta – a sensor, monitor and auditor that provides visibility into cloud deployments. The gallery has cloud fitness reports on GCP, AWS and Azure. Some interesting reports include: 1)how VM colocation impairs network bandwidth, and 2) tale of 2 cloud regions, London vs Singapore. Take a look and we'd love to get some feedback https://sensei.clockwork.io/user/gallery/
On Congestion control, an edge-based solution is coming soon. If you're interested in a private beta, email us at [email protected]
Re:Clockwork raises $21M to keep server clocks in sync
by galeaspablo on Saturday March 19, 2022 @05:07AM
(#30732304)
This is exactly what I was looking for. Thank you. It’s a shame fundamental publications aren’t part of PR articles. I’d also love to see better details on their website. Oh well, I cant expect everything to work like academia — c’est la vie.
Re:Clockwork raises $21M to keep server clocks in sync
by shiftingleft on Saturday March 19, 2022 @07:36AM
(#30732979)
> I also haven't seen any work of his using ML, that may just be a buzzword thrown in the PR release.
The first article you reference includes something about Support Vector Machines (SVMs).
Clock synchronization: https://www.usenix.org/conference/nsdi18/presentation/geng
I think the TechCrunch article doesn't really explain their application of clock synchronization well. Here are the other relevant papers and my attempt at explaining the general idea below.
Network edge-based measurement (one-way delay?): https://www.usenix.org/system/files/nsdi19-geng.pdf
Congestion Control: https://www.usenix.org/system/files/nsdi21-liu.pdf
Each paper I've listed builds on the last. Their method to synchronize clocks made accurate and efficient measurement of one-way delay possible with commodity hardware. This measurement of one-way delay occurs at the edge, allowing them to "hold" incoming packets at the edge for extremely small periods to reduce congestion (latency) while maintaining throughput. From my understanding, traditional congestion control algorithms require rich telemetry from the entire network, which is likely not accessible in a public cloud environment. Balaji and clockwork's algorithms only need to make these measurements from the edge (which customers in public cloud have access to).
I'm curious to see how all this will scale for multi-region deployments. If the latency between VMs from region 1 and region 2 is significant, I wonder if the measurement will actually be useful in deciding to "hold" the packets.