We've been evaluating Cato SASE Cloud for our primary WAN overlay, and while general application performance has been acceptable, we've encountered a severe and consistent performance degradation with a specific class of traffic: large file transfers. This isn't a general latency complaint, but a pathological drop in throughput under certain conditions that renders practical workflows unusable.
The observed behavior is as follows: transferring large single files (e.g., virtual machine disks, database backups, ISO images) from our on-premises data center to an AWS S3 bucket, both sites connected via Cato sockets, starts at expected line rates (~90 Mbps) but then drops precipitously to between 2-5 Mbps after approximately 60-90 seconds. The transfer then continues at this crippled speed to completion. Crucially, this does not happen with multi-gigabyte files comprised of many smaller files (like a source code repository), nor is it evident in synthetic throughput tests like iperf3. The problem is isolated to single-stream, bulk TCP transfers of large, contiguous data.
My initial troubleshooting has ruled out several common culprits:
* **Source/Destination Disk I/O:** Both source storage and S3 show no bottlenecks; transfers using other paths (direct Internet, a different VPN) achieve full bandwidth.
* **Cato Policy Rules:** No throttling rules are configured. Application awareness is enabled, but classifying the traffic as "Amazon" or "Generic" makes no difference.
* **Underlying Internet Links:** Both sides have stable, low-latency, low-loss connections. The issue reproduces across different source files and target AWS regions.
This pattern strongly suggests an interaction with Cato's traffic inspection or optimization engines. The time-based decay points to a TCP window or buffer management issue, perhaps within Cato's own packet processing pipeline. I am particularly interested in whether others have encountered similar behavior and what diagnostic steps within the Cato Management Application proved useful.
Key questions for the community:
* Have you observed similar single-stream throughput collapse, and did you identify a specific condition (e.g., file type, specific protocol, specific cloud provider) that triggers it?
* What Cato PoV metrics or internal logs are most indicative of throughput bottlenecks? I've been reviewing `Throughput` and `Traffic` widgets, but they lack granularity for this flow.
* Are there known adjustments to the Cato Socket configuration or TCP settings within the Cato Cloud that can mitigate this? I am aware of the "Optimize for throughput" setting on the socket's link, but enabling it did not resolve the issue.
My immediate next step is to conduct a controlled packet capture simultaneously at the source and a Cato PoV to identify where packet loss or window size collapse is occurring. I will also be testing with different TCP congestion algorithms on the source.
—Chris
Data over dogma
That's a very specific and well-documented problem. The pattern you describe, where performance is fine initially and then tanks, strongly points to something in the flow getting penalized or throttled after a certain threshold is crossed.
Since you've ruled out disk I/O, my mind goes to how the traffic might be classified as it moves through Cato's policy engine. Is it possible that after a certain data volume, the transfer is being re-categorized into a lower-priority traffic class? Maybe it's initially flagged as "general bulk" but then gets mistaken for "background" or "scavenger" traffic after a sustained period. Might be worth double-checking any application or sub-application policies, even if they seem unrelated on the surface.
Have you engaged with Cato support on this yet? Their visibility into the flow metrics and policy logs for that specific session would likely show the moment where the throughput drops, and they should be able to see if a policy action correlates with it.
Keep it constructive.