VL2: A Scalable and Flexible Data Center Network
Proceedings of the ACM SIGCOMM 2009 conference on Data communication, 2009 · paper · Computer science
Presents VL2, a data center network architecture offering uniform high capacity, performance isolation between services, and Ethernet semantics, using flat addressing, Valiant Load Balancing and end-system address resolution. A working prototype shuffles large data volumes among servers at high efficiency.
Checked: PDF from microsoft.com, fetched 4 Oct 2026. Page numbers are those of that PDF.
4 findings
Reference or label Figure 6: the decapsulated packet delivered to D shows the inner destination "20.0.0.66", but D is labelled "D (20.0.0.56)" and every other header in the figure carries 20.0.0.55 → 20.0.0.56.
- p. 6 Figure 6, packet header at destination ToR/D
20.0.0.66
- p. 6 Figure 6, destination host label
D (20.0.0.56)
- p. 6 Figure 6, packet drawn next to destination D
20.0.0.55 20.0.0.66
Judge's note: I checked the crop and page 6. The packet box beside the destination ToR reads 20.0.0.55 | 20.0.0.66, and the destination host is D (20.0.0.56). Sec 4.2.1 says the ToR decapsulates and delivers the packet to the destination AA in the inner header, so the inner destination should be unchanged at 20.0.0.56.
Second check: another model agreed
Report a problem with this finding
Reference or label Sec 4.3.1: "As discussed in Section 3.1, servers can communicate with up to hundreds of other servers in a short time period". The concurrent-flow data are in Section 3.2 (Number of Concurrent Flows, Fig. 3).
- p. 7 Section 4.3.1, Characterizing requirements
As discussed in Section 3.1, servers can communicate with up to hundreds of other servers
- p. 7 4.3.1
As discussed in Section 3.1, servers can com-
- p. 7 4.3.1 Characterizing requirements
As discussed in Section 3.1, servers can communicate with up to hundreds of other servers in a short time period
Judge's note: Page 3, Sec 3.1 covers macroscopic trends (4:1 ratio, uplinks above 80%) and the instrumented 1,500-node cluster, with no per-server fan-out. Page 4, Sec 3.2 'Number of Concurrent Flows' (Fig. 3) reports about 10 flows typically, more than 80 at least 5% of the time, and rarely more than 100. The pointer should be to 3.2.
Second check: another model agreed
Report a problem with this finding
Reference or label Sec 5.3: "techniques such as STCP to make UDP “TCP friendly” are well known if needed [14]", but reference [14] is "TCP friendly rate control (TFRC): Protocol specification".
- p. 9 Section 5.3
techniques such as STCP to make UDP “TCP friendly” are well known if needed [14]
- p. 12 Reference [14]
TCP friendly rate control (TFRC): Protocol specification. RFC 3348, 2003.
- p. 9 Section 5.3, UDP paragraph
techniques such as STCP to make UDP “TCP friendly” are well known if needed
- p. 12 Reference [14]
TCP friendly rate control (TFRC): Protocol specification. RFC 3348
Judge's note: Page 9 text names STCP, while page 12 ref [14] (Handley, Floyd, Padhye, Widmer) is titled TFRC, so the acronym does not match the cited work. Inside the paper this is a name/citation mismatch, probably a slip for TFRC. Separately, the reference prints 'RFC 3348'. Rests on outside knowledge: TFRC is RFC 3448. That number is not judged here.
Second check: another model agreed
Report a problem with this finding
Wording Sec 5.5: "For updates, however, the performance impact of the number of directory servers is higher than updates because each update is sent to a single directory server". The comparison should be with lookups.
- p. 10 Section 5.5, Resilience and availability
the performance impact of the number of directory servers is higher than updates because each update is sent to a single directory server
- p. 10 5.5 Resilience and availability
is higher than updates because each update
- p. 10 5.5 Resilience and availability
the performance impact of the number of directory servers is higher than updates because each update
- p. 10
the performance impact of the number of directory servers is higher than updates
Judge's note: Page 10, Resilience and availability. The paragraph contrasts lookups, which go to two directory servers, with updates, which go to one. As printed, the sentence compares updates with themselves.
Second check: another model agreed
Report a problem with this finding
8 minor (typos and the like; most checked by the judge only)
Wording Introduction claims split ratios "within 1% of optimal fairness index", but Section 5.2 reports only that "the VLB split ratio fairness index averages more than 0.98 for all Aggregation switches".
- p. 2 Introduction, contributions bullet 3
within 1% of optimal fairness index
- p. 9 Section 5.2
the VLB split ratio fairness index averages more than 0.98 for all Aggregation switches
- p. 9 Section 5.2 and Figure 10
averages more than 0.98 for all Aggregation switches
- p. 2 Intro contributions
within 1% of optimal
Only the authors can say what is right here.
Judge's note: Page 2 bullet 3 reads "(within 1% of optimal fairness index)". Page 9, Sec 5.2 reads "averages more than 0.98 for all Aggregation switches". In Fig. 10 the Agg1 and Agg2 traces sit near 0.98–1.0, while Agg3 dips well below 0.98 at times. Since the optimum Jain index is 1.0, 'more than 0.98' supports being within about 2%. The results never report 0.99, so the headline figure is stronger than what is reported. Only the authors can say which number is right.
Second check: another model agreed
Report a problem with this finding
Wording Introduction says traffic is "cycling among 50-60 different patterns during a day", but Sec 3.3 says that even with 50–60 clusters "the fitting error remains high (60%)" and classifies traffic into "the 40 best TM clusters" for the cycling analysis (Fig. 4).
- p. 2 Introduction, contributions bullet 1
cycling among 50-60 different patterns during a day
- p. 4 Section 3.3, Instability of traffic patterns
we find the 40 best TM clusters using the technique above
Only the authors can say what is right here.
Judge's note: Page 2 bullet 1 vs page 4, Sec 3.3. In Sec 3.3, 50–60 is the number of clusters that still fails to summarise the traffic. The cycling and run-length analysis (Fig. 4a, y-axis 0–40) uses 40 clusters. The introduction loosely paraphrases the 50–60 result as the number of patterns the traffic cycles among, which matches neither analysis as reported.
Second check: another model agreed
Report a problem with this finding
Wording Introduction says "spending less than 100 s in each pattern at the 60th percentile", but Sec 3.3 reports "The run length is 1 to the 60th percentile", with runs counted in 100 s intervals, i.e. about 100 s rather than less than 100 s.
- p. 2 Introduction, contributions bullet 1
spending less than 100 s in each pattern at the 60th percentile
- p. 4 Section 3.3
The run length is 1 to the 60th percentile.
Judge's note: Page 4: one TM is computed per 100 s interval, and Fig. 4b gives run lengths in intervals. A run length of 1 is one 100 s interval, so at this resolution the data support 'about/at most 100 s', not strictly 'less than 100 s'. This is a minor wording imprecision.
Second check: another model agreed
Report a problem with this finding
Wording Sec 5.2 says "we created an experiment on our 75-node testbed", while the testbed is described as "80 servers and 10 switches" (Fig. 8, Sec 5).
- p. 9 Section 5.2
we created an experiment on our 75-node testbed
- p. 8 Figure 8 caption
VL2 testbed comprising 80 servers and 10 switches.
- p. 7 Section 5
an 80 server testbed and 10 commodity switches
Judge's note: Page 9 vs pages 7–8: 4 ToRs × 20 servers = 80. The shuffle used 75 servers, so the experiment may have used 75 nodes, but calling the testbed itself 75-node is inconsistent with the other descriptions.
Second check: another model agreed
Report a problem with this finding
Wording Summary: "Experiments with two data-center services showed that churn (e.g., dynamic re-provisioning of servers, change of link capacity, and micro-bursts of flows) has little impact on TCP goodput". No change of link capacity happens in the two-service experiments; the only link-capacity experiment (Sec. 5.4, Fig. 13) is a single all-to-all shuffle.
- p. 12 Section 8, Summary
churn (e.g., dynamic re-provisioning of servers, change of link capacity, and micro-bursts of flows) has little impact on TCP goodput
- p. 10 Figure 13
Aggregate goodput as all links to switches Intermediate1 and Intermediate2 are unplugged
Only the authors can say what is right here.
Judge's note: In Sec. 5.3 the two two-service experiments cover server re-provisioning (Fig. 11) and bursts of mice (Fig. 12), and service one's goodput is unaffected in both. Link capacity changes only in Sec. 5.4 / Fig. 13, a single-service shuffle. On the page 10 image, aggregate goodput there falls from about 58 to about 23 Gbps as links are unplugged, and the paper calls this 'graceful degradation' (about 90% of available capacity), not little impact. The Summary's grouping overstates this; the authors should clarify what they mean.
Second check: another model agreed
Report a problem with this finding
Typo Sec 5: "The ToRs switches have 2 10Gbps ports and 24 1Gbps ports" should read "The ToR switches".
- p. 8 Section 5, testbed description
The ToRs switches have 2 10Gbps ports and 24 1Gbps ports
Judge's note: Seen on page 8, first paragraph of the testbed description.
Second check: none (judge only)
Report a problem with this finding
Typo Sec 5.4 writes "over-subscription ratios between 1:1 and 3:1", while elsewhere the paper writes over-subscription as 1:N (1:5, 1:20, 1:240, "1:1 to 1:23").
- p. 10 Section 5.4
over-subscription ratios between 1:1 and 3:1
Judge's note: Page 10 vs pages 3 and 11. This is a notation inconsistency; the meaning is clear from context.
Second check: none (judge only)
Report a problem with this finding
Typo Reference [6] prints the author as "H. werner Braun" (lowercase 'werner').
- p. 12 Reference [6]
H. werner Braun
Only the authors can say what is right here.
Judge's note: Rests on outside knowledge: that the author is Hans-Werner Braun. The C020 crop shows 'K. C. Claffy, H. werner Braun, and G. C. Polyzos' with lowercase 'werner', so this is not an extraction artefact. It looks like a BibTeX name-parsing slip.
Second check: none (judge only)