Written by Johanna Sochos | March 1, 2018
The reasons for the measured saturation of app test durations can be found in the underlying phases of a file upload/download. As the illustration below reveals, the data transfer itself is only one part of the whole process. The other parts are essential for a real service and drive the customer experience.
However, the underlying file upload/download phases increase the test duration compared to plain HTTP transfers and are not usable for estimating the physical channel capacity.
Phases of a data upload/download to a third-party server like Facebook or Dropbox
Phases of a data upload/download to a third-party server like Facebook or Dropbox
Open Lightbox
- Transfers to Dropbox and Facebook are encrypted. Setting up an SSL session takes time since it requires several messages to be exchanged. In comparison, plain HTTP transfers without encryption to a self-hosted server without any upfront setup messages start immediately.
- After the SSL session is initiated, the real data transfer takes place.
- For uploads to Facebook and Dropbox, we see a large gap in the IP traffic where the upload is already complete but the client has not yet received confirmation of success. During this time span, the server is probably postprocessing the data, e.g. compressing pictures uploaded to Facebook to save storage space and allow faster downloads in the future. But also in the case of Dropbox where we don’t expect data compression since it is a cloud storage service, there is a certain time span dedicated to postprocessing, maybe for data storage optimization.
- For downloads, time is needed to render and display the new content on the screen.
- Finally, the confirmation of a successful upload is sent from the server to the client. This can be only one short IP packet, but it requires network connectivity.
For high network speeds, e.g. in good coverage LTE, the transfer phase itself can be very short with a duration close to zero seconds. In this case, the other phases are the dominant factors for test duration.
For changing test conditions, we see that the length of the other phases depends on many factors. These include the latency between client and server; server performance and load; device performance, and processing complexity of the transferred content.
What does the actual transfer phase in mobile data applications look like?
In the case of uploads to Facebook, we see an interesting behavior: Although the latencies are very similar, the throughput ramp-up takes much longer compared to plain HTTP transfer tests. A typical example looks like this:
Typical throughput ramp-up behavior for both plain HTTP and Facebook uploads: The transfer to Facebook needs 6 seconds to reach a stable throughput level compared to only 1 to 2 seconds for plain HTTP.
Typical throughput ramp-up behavior for both plain HTTP and Facebook uploads: The transfer to Facebook needs 6 seconds to reach a stable throughput level compared to only 1 to 2 seconds for plain HTTP.
Open Lightbox
The underlying reason is not clear. It might be some optimization strategy in place on the Facebook servers, maybe for congestion control or network resource-saving. However, the implication is very clear: Even when looking at only the transfer phase, the average throughput of a Facebook test cannot reach the average plain HTTP throughput.
Consequently, we need to look at the maximum throughput achieved during a test in order to learn something about the possible network limitations when using third-party services such as Facebook. And the transfer phase has to be long enough to reach the maximum possible throughput. This can only be achieved by using larger files for transfer.
The average throughput of a Facebook test cannot reach the average plain HTTP throughput.
We wanted to know whether Facebook and plain HTTP are at least comparable with respect to the maximum throughput reached during a transfer phase or if there might be further limitations introduced by the third-party service. We, therefore, conducted tests in Switzerland with larger file sizes for upload and received the following results:
Durations (left) and maximum throughputs (right) of uploads to Facebook compared to plain HTTP for different file sizes:. Durations saturate faster for smaller files and the maximum throughputs for smaller files cannot reach plain HTTP throughputs.
Durations (left) and maximum throughputs (right) of uploads to Facebook compared to plain HTTP for different file sizes: Durations saturate faster for smaller files and the maximum throughputs for smaller files cannot reach plain HTTP throughputs.
Open Lightbox
The test duration shown in the left graph behaves as expected. Saturation is reached at higher HTTP throughputs when larger files are transferred because the slow ramp-up time contributes less to the overall transfer time. In addition, the level of saturation is higher for larger files since the server also needs more time for postprocessing.
In the other graph, the maximum throughput reached during uploads to Facebook is plotted against the maximum plain HTTP throughput. Only for very large files can Facebook approach the maximum plain HTTP throughput. For files below 50 Mbyte, the time for reaching the end of the slow throughput ramp-up is obviously not always enough.
The similarity in the maximum throughputs for large files implies, though, that there is no further limitation of the transfer speed in the measured throughput range for Facebook.
Answers to QoE of mobile data applications
What does this mean for testing QoE? How should mobile data application tests be used in mobile network testing? What is a good strategy to combine information from technical tests with QoE results in network optimization?
Stay tuned and get the answers in the final post of this series, or read part 1 in the meantime.
