1. Identify which part is slow
A slow handoff can mean waiting for files to be prepared, scanning a directory, uploading, processing at the destination, or downloading as the recipient. Start and stop a timer at each boundary. A fast upload does not help the buyer if the receiving team still cannot use the package.
- Record total bytes, file count, tool version and the selected transfer path.
- Write down when the sender starts, when upload completes and when the recipient finishes downloading.
- Choose a non-sensitive test workload that represents the real job. Keep a copy of the original for verification.
2. Separate endpoint limits from route limits
TCP throughput depends on bottleneck bandwidth, round-trip time and the amount of data the endpoints can keep in flight. RFC 6349 describes measuring these together rather than judging a path by the purchased link speed alone. Inspect source reads and destination writes as well: the application cannot deliver data faster than the surrounding workflow can supply and accept it.
| Observation | Next check | Avoid concluding |
|---|---|---|
| Local and distant transfers are both slow | Source reads, destination writes, CPU and application limits | Distance must be the cause |
| Local transfer is fast; remote transfer is slow | RTT, retransmissions, endpoint buffers and competing traffic | Buying more bandwidth will definitely fix it |
| One large file is fast; many small files are slow | Directory scan time and per-file processing | Every workload will match the large-file result |
| Upload finishes; recipient is still waiting | Package state, recipient access and download path | Upload complete means delivery complete |
3. Run a controlled comparison
Arrange an approved test window with the endpoint owners. Do not run saturating network tests on a production path without permission. Keep security controls enabled and record any rate caps or competing jobs.
- 1Transfer the same representative workload using your current tool and the proposed alternative.
- 2Use the same endpoints and comparable storage. Note configuration, concurrency and test start times.
- 3Repeat the comparison rather than publishing only the best run. Record failures and manual recovery work too.
- 4Verify the delivered files and compare complete elapsed times. Keep protocol-only tests separate from end-to-end file delivery.
4. Bring an actionable evaluation brief
Workload: total bytes / file count / largest file
Source and destination: region / storage / endpoint type
Current tool and configuration:
Observed upload and recipient completion times:
RTT / loss observations and how they were measured:
Delivery deadline:
Required access controls:
Success criteria and test owner:For Ripton, distinguish the native Desktop transfer path from an eligible Web Edge browser path. Ask to demonstrate the path you will actually deploy, including recipient access and completion. If storage or the last-mile connection is the bottleneck, address that constraint rather than assuming a protocol change removes it.
- Send with Ripton Desktop
Follow the existing sender workflow and verification steps.
- RFC 6349: TCP throughput testing
Primary reference for RTT, bandwidth, window sizing and throughput test methodology; consulted October 6, 2026.