1. 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

2. 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
Nexus S Android 2.3
on WiFi connection
(3G, 4G would be slower)

3. 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

4. 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

5. 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

6. 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?

7. 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

8. 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?

9. 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:

10. Estimating Components of TTFBOS
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

11. 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

12. 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

13. 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%

14. 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

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

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

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

18. 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