Emir Halepovic, Jeffrey Pang, Oliver Spatscheck AT&T Labs - Research Can you GET me now? Estimating the Time-to-First-Byte of HTTP Transactions with Passive Measurements Emir Halepovic, Jeffrey Pang, Oliver Spatscheck AT&T Labs - Research

Motivation Click! Request web object First byte of web object Delays of 250 milliseconds or more in web page load time will cause users to visit less often [Google, Microsoft 2012] A significant component of web page load time is the time-to-first-byte (TTFB), and TTFB is mostly comprised of network latencies MyApp Click! Request web object First byte of web object Time to first byte www.webpagetest.org Nexus S Android 2.3 on WiFi connection (3G, 4G would be slower)

Current State-of-the-Art Network operators have compelling interest to monitor TTFB since changes in their network can directly affect it Current approach: Modest number of active probes in different locations measure TTFB directly, using custom or web-based tools [e.g., keynote.com, webpagetest.com] Problem: Not practical to scale active probes to cover entire cellular network and probes may not represent real user workloads (different devices, different webpages, etc.) Question: Can we estimate TTFB of real traffic using passive traffic analysis? Probe

Goals Estimate latency passively from inside network core Distinguish connections with Radio Resource Control (RRC) State Transition Representative of user experience Scalable CPU cost – simplicity Memory footprint – minimal state Robust Tolerant to some level of packet loss and delay Correctly measure many different devices Correct even when RRC state machine changes

Typical packet exchange for a new HTTP flow TTFB Overview Goal: Estimate TTFB of HTTP transactions at probe Method: Analyze TCP packets comprising HTTP traffic We define TTFB as: elapsed time between TCP SYN departure from device operating system and first byte of HTTP data arrival Other definitions may include DNS and/or HTTP redirects - service providers have other tools to quantify the delay of these aspects SYN SYN-ACK ACK HTTP-GET HTTP-DATA GET-ACK DATA-ACK TTFB PROBE DNS Request DNS Response … Optional: if domain name is not cached (30-39% requests) Object can start rendering at this time Click! Typical packet exchange for a new HTTP flow

Common metric: Round-Trip-Time (RTT) SYN SYN-ACK ACK HTTP-GET HTTP-DATA GET-ACK DATA-ACK RTT PROBE Estimate r0 r1 RTT is typically estimated as inter-arrival between corresponding packets during TCP hand-shake: RTT = r1 – r0 Can we compute TTFB as a function of RTT?

Why not use RTT? Is TTFB a simple function of RTT? Estimate PROBE r0 r1 SYN SYN-ACK ACK HTTP-GET HTTP-DATA GET-ACK DATA-ACK OS TTFB Radio STT HTTP-TT Is TTFB a simple function of RTT? Not in cellular network! Important delay components are not captured by RTT: STT: State Transition Time, i.e., time that packet is waiting for radio connection It will not always occur, but lasts ~2 seconds in 3G Server Delay: Time that web server takes to respond HTTP-TT: HTTP Transmission Time, which is higher than RTT because HTTP packets are larger than TCP SYN/SYN-ACK Server Delay

A New Approach to Estimate TTFB PROBE SYN SYN-ACK ACK HTTP-GET HTTP-DATA GET-ACK DATA-ACK OS RTT TTFB Server Delay Radio STT HTTP-TT TS0 TS1 TS2 Approach: Instead of arrival times at probe, we can use timestamps in TCP segments inserted by device OS Benefit: Add device’s view of delay Most TCP connections use Timestamps (85%) Main Challenge: Units of timestamps TSi are not known and differ across devices. How do we convert them to standard units?

Developing Our Estimate of TTFB PROBE SYN SYN-ACK ACK HTTP-GET HTTP-DATA GET-ACK DATA-ACK OS RTT TTFB Server Delay Radio STT HTTP-TT TS0 TS1 TS2 r0 r1 r2 Timestamp granularity: Assuming that device-to-probe delay for ACK packets is fixed, we can estimate timestamp granularity G as: We thus estimate TTFB as:

Estimating Components of TTFB OS Radio PROBE TTFB STT RTT HTTPTT Server Delay G t0 TS0 STT t11 SYN r0 RTT SYN-ACK t1 TS1 ACK TTFB r1 HTTP-GET Server Delay HTTP-TT GET-ACK By recording timestamps and packet arrival times at the probe, we can estimate all the components of the TTFB HTTP-DATA t2 TS2 DATA-ACK r2

Evaluation Summary of results: Estimation is accurate, scalable, and simple to implement TTFB illustrates high variation for different devices, applications, domains etc. whereas RTT does not Experimental setup Packet trace collection from devices and network elements covering large geographic area Probe UE Traces Validate G and TTFB RNC Traces Validate ST Network Traces Estimate TTFB

TTFB Validation Estimated TTFB distribution is very close to the actual (a) Browsing without STT (b) Browsing with STT [Results for UE with G=1 ms shown, results for UE with G=100ms are similar] Latencies are normalized by same constant

Results: Composition of TTFB STT makes up an average 68% of TTFB, when present HTTP-TT is higher than RTT (excluding server delay) Server delay is not negligible PROBE SYN SYN-ACK ACK HTTP-GET HTTP-DATA GET-ACK DATA-ACK OS RTT TTFB Server Delay Radio STT HTTP-TT STT RTT HTTPTT-Q Q=Server Delay No ST 0% 32% 50% 18% With ST 68% 7% 12% 13%

Results: TTFB vs. RTT for Devices Newer HSPA devices show improved TTFB and RTT, but same TTFB with STT (HSUPA/HSPA+ vs. HSDPA) Reason: All HSPA devices subject to same radio signaling, transitions LTE shows major improvement over newer HSPA in STT, but minor improvement in TTFB and RTT Averages with 95% confidence intervals

Results: TTFB vs. RTT for Domains TTFB can show large difference across domains while RTT barely changes

Results: TTFB vs. RTT for Domains TTFB can show large difference across domains while RTT barely changes

Results: TTFB vs. RTT for Applications Applications under the same domain can have identical RTT but different TTFB (e.g., domains B and C)

Summary and Future Work We presented an accurate passive estimate for TTFB We showed RTT does not fully reflect the TTFB Missing important latency components (STT, server delay, etc.) TTFB offers better performance estimate than RTT Future work Explore ways to include DNS and HTTP redirect delays into TTFB definition, as these impact the user experience also