DCTCP: Efficient Packet Transport for the Commoditized Data Center
2010 · paper · Computer science
Proposes DCTCP, a TCP-like protocol for data centers using Explicit Congestion Notification, based on measurements of a 6000-server cluster. It matches or beats TCP throughput with 90% less buffer space, and handles 10 times more background traffic.
Checked: PDF from cs.princeton.edu, fetched 5 Oct 2026. Page numbers are those of that PDF.
5 findings
Reference or label The static buffer is given as "a static allocation of 100 packets to each port" and "a static buffer of 100 packets at each port", but the timeout threshold is justified by "(35 × 2× 1.5KB > 100KB)"; at the 1.5KB packet size used in that expression 100 packets is 150KB, and 35 × 2 = 70 packets does not exceed 100 packets.
- p. 9 Section 4.2.1, Basic incast
static allocation of 100 packets to each port
- p. 9 Section 4.2.1, after Figure 18 discussion
static buffer size (35 × 2× 1.5KB > 100KB)
- p. 9 Section 4.2.1, Importance of dynamic buffering
static buffer of 100 packets at each port
- p. 9 Section 4.2.1, Basic incast, setup
was replaced with a static allocation of 100 packets to each port
Only the authors can say what is right here.
Judge's note: All three passages read on the page 9 image. 35 × 2 × 1.5KB = 105KB exceeds 100KB but not 150KB. I searched the text for a statement that the switch counts buffer in smaller cells or that packets are other than 1.5KB in this experiment and found none. Figure 18 shows DCTCP timeouts starting between 35 and 40 senders, which fits a buffer of about 100KB, so the unit in "100 packets" (or the size in "100KB") is the likely slip; only the authors can say which.
Second check: another model agreed
Report a problem with this finding
Reference or label Reference [30] prints its author list as "I. R. Sangtae Ha and L. Xu. Cubic: A new TCP-friendly high-speed TCP variant."
- p. 12 References, [30]
I. R. Sangtae Ha and L. Xu. Cubic: A new TCP-friendly high-speed TCP variant.
- p. 12 References [30]
I. R. Sangtae Ha and L. Xu.
Only the authors can say what is right here.
Judge's note: Rests on outside knowledge: the CUBIC paper's authors are Sangtae Ha, Injong Rhee and Lisong Xu, so the entry should read "S. Ha, I. Rhee, and L. Xu". On the page 12 image the entry reads as quoted. The garbling shows on the page itself: it is the only entry with a spelled-out given name, placed after a pair of initials, where every other entry uses initials plus surname.
Second check: another model agreed
Report a problem with this finding
Wording Abstract: "a 10X increase in foreground traffic does not cause any timeouts", but Section 4.3 (scaled traffic) reports "only 0.3% suffer from timeouts with DCTCP" and "even at 10X larger size, only 0.3% of queries experience timeouts under DCTCP".
- p. 1 Abstract
a 10X increase in fore- ground traffic does not cause any timeouts
- p. 11 Section 4.3, Scaled traffic
0.3% suffer from timeouts with DCTCP
- p. 11 Section 4.3, Scaled traffic
only 0.3% of queries experience timeouts under DCTCP
- p. 1 Abstract, last sentence
does not cause any timeouts
Only the authors can say what is right here.
Judge's note: Read the abstract on page 1 and Section 4.3 on page 11. The only experiment with a 10X increase in query (foreground) traffic is the scaled benchmark, where 0.3% of queries time out under DCTCP. "No queries suffer from timeouts with DCTCP" is stated only for the unscaled baseline, and the no-timeout incast microbenchmarks are not described as a 10X increase. The abstract overstates the result; it hedges itself with "largely eliminating", so rated as wording rather than a wrong number.
Second check: another model agreed
Report a problem with this finding
Wording Short-message size range differs: Section 1 "delay sensitive short messages (100KB to 1MB)" and Section 4.3 "short messages (100KB-1MB)", but Section 2.2 "short message flows, 50KB to 1MB in size".
- p. 1 Section 1, last paragraph
delay sensitive short messages (100KB to 1MB)
- p. 3 Section 2.2, Background Traffic
short message flows, 50KB to 1MB
- p. 11 Section 4.3
short messages (100KB-1MB)
- p. 3 Section 2.2, Background Traffic
50KB to 1MB
Only the authors can say what is right here.
Judge's note: Read page 1, page 3 and page 11. The same traffic class has a lower bound of 100KB in the introduction and evaluation and 50KB in the workload characterization; no text explains the difference (the 100KB-1MB histogram bin in Figure 22 may be the source). This cluster is scoped to the short-message range; the long-flow and query ranges are judged in C003 and C004.
Second check: another model agreed
Report a problem with this finding
Wording §4.3 says of Figure 24 "The results show DCTCP performs significantly better than TCP for both update and query traffic", but Figure 24 and the next sentence report short messages (100KB-1MB) and query traffic, not update flows.
- p. 11 Section 4.3, Scaled traffic
performs significantly better than TCP for both update and query traffic
- p. 11 Figure 24 x-axis
Short messages
- p. 11 Section 4.3, paragraph on Figure 24
better than TCP for both update and query
Only the authors can say what is right here.
Judge's note: Page 11 image: Figure 24's x-axis groups are "Short messages" and "Query"; the preceding sentence says the figure shows "the short messages (100KB-1MB) and the query traffic" and the following one gives the short-message and query improvements. The paper defines update flows as the large 1MB+ background flows (§2.2: "large, 1MB to 50MB, update flows"; §4.3: "update flows larger than 1MB"), distinct from short messages. §2.2 does say short messages "update control state", so "update" may be loose wording for short-message; either way the word does not match the figure.
Second check: another model agreed
Report a problem with this finding
24 minor (typos and the like; most checked by the judge only)
Wording Abstract: "measurements of a 6000 server production cluster" and Section 6: "from a 6000 server data center cluster", but Section 2.2: "workloads in three production clusters ... We instrumented a total of over 6000 servers in over 150 racks. The three clusters ...".
- p. 1 Abstract
We present measurements of a 6000 server
- p. 12 Section 6, Final Remarks
from a 6000 server data center cluster
- p. 3 Section 2.2, first paragraph
We next measure the attributes of workloads in three production
- p. 3 Section 2.2, second paragraph
We instrumented a total of over 6000 servers in over 150 racks.
Judge's note: Read the abstract (page 1), Section 2.2 (page 3) and the Final Remarks crop (page 12). The abstract and conclusion describe one 6000-server cluster; Section 2.2 says the 6000 servers are a total across three production clusters. "Cluster" may be used loosely for the whole deployment, so this is a consistency point rather than a clear error.
Second check: another model agreed
Report a problem with this finding
Wording "these microbenchmarks allow us to individually test DCTCP for fairness, high throughput, high burst tolerance, low latency and high performance isolation ... On all these metrics, DCTCP significantly outperforms TCP." The same section reports equal throughput: "both TCP and DCTCP achieve the maximum throughput of 0.95Gbps" and "Long-lived flows get the same throughput under both TCP and DCTCP."
- p. 10 Section 4.2.3, summary paragraph
On all these metrics, DCTCP significantly outperforms TCP.
- p. 8 Section 4.1, Throughput and queue length
both TCP and DCTCP achieve the maximum through- put of 0.95Gbps
- p. 10 Section 4.2.3
Long-lived flows get the same throughput under both TCP and DCTCP.
- p. 10 Section 4.2.3, summary paragraph
On all these metrics, DCTCP
Judge's note: Read page 10 (§4.2.3 summary) and page 8 (§4.1). Throughput is one of the listed metrics and is reported as the same for both protocols at 1Gbps, and at 10Gbps DCTCP "gets the same throughput as TCP" once K exceeds 65; TCP is also described as "fair on average". The abstract's wording, "the same or better throughput", matches the results; the summary sentence overstates them for throughput.
Second check: another model agreed
Report a problem with this finding
Wording Figure 18 caption: "DCTCP performs better than TCP and then converges at 35 senders"; in the plots DCTCP is still well below TCP at 35 servers and the DCTCP (300ms) curve meets TCP (300ms) only at 40.
- p. 9 Figure 18 caption
verges at 35 senders
- p. 9 Figure 18(a) and (b), points at 35 and 40 servers
DCTCP (300ms)
Judge's note: Viewed the Figure 18 crop. At 35 servers DCTCP (300ms) query delay is about 20ms against several hundred ms for TCP (300ms), and the DCTCP timeout fraction is about 0.01. At 40 servers DCTCP (300ms) reaches the TCP (300ms) level (fraction about 1.0), while DCTCP (10ms) is at about 0.4 against about 1.0 for TCP (10ms). The body text says DCTCP begins to suffer timeouts once senders reach about 35, so the caption probably means that degradation starts at 35; as worded it misplaces the convergence point.
Second check: another model agreed
Report a problem with this finding
Wording "all 41 machines participate. Each machine requests 25KB of data from the remaining 40 machines (total 1MB). In other words, 40 incast experiments happen all at once.": with 41 requesting machines there are 41 simultaneous incasts, each with 40 senders.
- p. 10 Section 4.2.1, All-to-all incast
all 41 machines participate. Each machine requests 25KB of data from the remain- ing 40 machines (total 1MB). In other words, 40 incast experiments happen all at once.
- p. 10 Section 4.2.1, All-to-all incast
except all 41 machines
- p. 10 Section 4.2.1, All-to-all incast
40 incast experiments
Only the authors can say what is right here.
Judge's note: Read on the page 10 image, §4.2.1 All-to-all incast. 40 × 25KB = 1MB is consistent. The count of concurrent incasts follows the number of requesting machines (41), not the fan-in (40). No statement elsewhere says one machine does not issue requests. Off by one, with no effect on the result.
Second check: another model agreed
Report a problem with this finding
Wording §4.3 uses "45 servers" and has each server "send a query to all other servers in the rack, each of which then send back a 2KB response (45 × 2KB ≈100KB total response size)"; all other servers is 44, and the scaled experiment on the same testbed says "(with 44 servers, each individual response is just under 25KB)".
- p. 10 Section 4.3
query to all other servers in the rack, each of which then send back a 2KB response (45 × 2KB ≈100KB total response size)
- p. 11 Section 4.3, Scaled traffic
with 44 servers, each individual response is just under 25KB
- p. 10 Section 4.3, traffic generation
45 × 2KB
- p. 10 Section 4.3, setup
45 servers connected to a Triumph top of rack switch
Only the authors can say what is right here.
Judge's note: Read page 10 (§4.3 setup and traffic generation) and page 11 (Scaled traffic). With 45 servers a query has 44 responders: 44 × 2KB = 88KB, and 45 × 2KB = 90KB, both rounded loosely to ≈100KB. 1MB/44 is about 22.7KB, loosely "just under 25KB". The responder count is 45 in one place and 44 in the other; the extra 10Gbps machine is described as a stand-in for the rest of the data center, not as a rack server. The '≈' makes the size approximate, so the point is the 45 versus 44 count.
Second check: another model agreed
Report a problem with this finding
Wording §4.3: "flows from 100KB-1MB see a 3ms/message benefit at the mean"; in Figure 22(a) the 100KB-1MB bars differ by roughly 1.5-2ms (DCTCP about 4.7ms, TCP about 6.3ms on the log axis).
- p. 11 Section 4.3, paragraph on Figure 22
see a 3ms/message
- p. 11 Figure 22(a) Mean, 100KB-1MB bars
100KB-1MB
Only the authors can say what is right here.
Judge's note: Read Figure 22(a) on the enlarged crop. With the 4 and 8 gridlines as scale, the DCTCP bar tops out a little above 4 (about 4.7) and the TCP bar well below 8 (about 6.3), a gap of about 1.6ms; a 3ms gap would need the TCP bar at about the 8 gridline, which it clearly is not. The companion claim, 9ms at the 95th percentile, matches the labelled bars in panel (b) (22 and 13). Values are read from an unlabelled log-scale bar chart, so the reading is approximate and the text may quote unplotted numbers; hence a query to the authors rather than a correction.
Second check: another model agreed
Report a problem with this finding
Wording §4.3: "DCTCP can handle substantially more traffic without any adverse impact on performance" and "while performing better than it does with TCP today"; for queries, DCTCP at 10X has a 95th-percentile completion time of 21ms (Figure 24) against about 7ms for baseline TCP (Figure 23), and 0.3% timeouts where baseline DCTCP had none.
- p. 11 Section 4.3, 'three key points'
while performing better than it does with
- p. 11 Section 4.3, paragraph after Figure 24 discussion
impact on performance
- p. 11 Figure 24, Query, DCTCP bar
21
- p. 11 Figure 23, 95th percentile bars
95th
Judge's note: Page 11 image. Figure 24: DCTCP query bar labelled 21, short messages 15. Figure 23 (baseline): 95th percentile about 5ms DCTCP and about 7ms TCP, read from the bars. The claim holds for short messages (15ms at 10X vs 22ms for baseline TCP in Figure 22(b)) and for query timeouts (0.3% vs 1.15%), which is the comparison the text actually makes. Footnote 13 acknowledges that the minimum query completion time rises 10X with 10X larger queries, so the longer query time is partly disclosed and expected. What remains is that the unqualified wording holds only for timeouts and short-message latency, not for query completion time. Minor overstatement.
Second check: another model agreed
Report a problem with this finding
Typo Section 2: "traffic patterns that result from these application structure" (number disagreement; "this application structure" or "these application structures").
- p. 2 Section 2, opening paragraph
these application structure
- p. 2 §2 intro
result from these application structure
Judge's note: Visible in the crop of page 2: "these application structure, and identify three performance impairments".
Second check: none (judge only)
Report a problem with this finding
Typo Typos in running text: "DCTCP consistently ourperforms TCP" (p11); "a good measure of the the length" and "deliberating delaying them" (p4); "upon it’s arrival" (p5); "recovery from packet lost" and "cuts it’s window size" (p6); "differences in time cause by DCTCP’s" (p7); "from these application structure" (p2).
- p. 11 Section 4.3, last paragraph
DCTCP consistently ourperforms TCP
- p. 11 Section 4.3, last sentence
ourperforms
- p. 4 2.3.3
a good measure of the the length
- p. 4 2.3.2
deliberating delaying them
Judge's note: Each one read on the page image or crop; all are in the typeset text, none is an extraction artefact. Intended: outperforms; the length; deliberately; its (twice); packet loss; caused by; this application structure (or these application structures).
Second check: none (judge only)
Report a problem with this finding
Typo Text cites "Figure 3(a)" and "Figure 3(b)", but the two panels of Figure 3 and its caption carry no (a)/(b) labels.
- p. 3 Figure 3 caption
Figure 3: Time between arrival of new work for the Aggrega-
- p. 3 §2.2
Figure 3(a) shows the CDF of time between arrivals of
Judge's note: Checked the Figure 3 crop: the panels are identified only by their legends (Query Traffic, Background Traffic) and the caption has no panel letters, while Section 2.2 refers to Figure 3(a) and 3(b). The panels are easy to identify from the legends, so this is cosmetic.
Second check: none (judge only)
Report a problem with this finding
Typo Section 2.3.2: "desynchronize the responses by deliberating delaying them by a random amount of time" (should read "deliberately delaying").
- p. 4 Section 2.3.2
responses by deliberating delaying them
- p. 4 §2.3.2
deliberating delaying them by a random amount
- p. 4
responses by deliberating delaying them by a random amount of
Judge's note: Visible on the page 4 image, right column. The Figure 8 caption on the same page uses "deliberately delayed".
Second check: none (judge only)
Report a problem with this finding
Typo Section 2.3.3: ""RTT+queue" is a good measure of the the length of the packet queue" (duplicated "the").
- p. 4 Section 2.3.3
a good measure of the the length
- p. 4 §2.3.3
a good measure of the the length of the
- p. 4
T+queue” is a good measure of the the length of the packe
Judge's note: Visible on the page 4 image; both words are on the same line, so it is not a line-break artefact.
Second check: code check
Report a problem with this finding
Typo "if the queue occupancy is greater than K upon it’s arrival": "it’s" should be the possessive "its".
- p. 5 Section 3.1, (1) Simple Marking at the Switch
upon it’s arrival
- p. 5 §3.1 (1) Simple Marking at the Switch
greater than K upon it’s arrival
Judge's note: Read on the page 5 image, §3.1 (1) Simple Marking at the Switch. The apostrophe is printed; the possessive is meant.
Second check: none (judge only)
Report a problem with this finding
Typo "While TCP always cuts it’s window size by a factor of 2": "it’s" should be the possessive "its".
- p. 6 Section 3.1, before Equation (2)
TCP always cuts it’s window size
- p. 6 §3.1, after Eq. (1)
TCP always cuts it’s window size by a factor of 2
Judge's note: Read on the page 6 image, §3.1 just before Equation (2). The apostrophe is printed.
Second check: none (judge only)
Report a problem with this finding
Typo "or recovery from packet lost are left unchanged": "packet lost" should be "packet loss".
- p. 6 Section 3.1, before Equation (2)
recovery from packet lost
- p. 6 §3.1
recovery from packet lost are left un-
Judge's note: Read on the page 6 image, §3.1 before Equation (2). The noun is required.
Second check: none (judge only)
Report a problem with this finding
Typo "DCTCP queue length is stable around 20 packets (i.e., equal to K + n, as predicted in § 3)": §3 (Equation 10) writes the prediction as "K + N" with N the number of flows; lower-case n is not defined here and is used in §4.2.1 for the number of servers.
- p. 8 Section 4.1, Throughput and queue length
stable around 20 packets (i.e., equal to K + n, as predicted in § 3)
- p. 6 Equation (10)
= K + N
- p. 8 §4.1 Throughput and queue length
equal to K + n, as predicted in § 3
Judge's note: Read page 8 (§4.1) and Equation (10) on page 6, which prints Qmax = ... = K + N. The symbol slip is real. The numeric part of the finding is not upheld: in a 300-dpi render of Figure 13 the 'DCTCP 2 flows' curve sits at about 20 packets and the 'DCTCP 20 flows' curve at roughly 30-40 packets, which agrees with K + N = 22 and 40. 'Around 20 packets' is loose wording for the 20-flow case only.
Second check: none (judge only)
Report a problem with this finding
Typo "the actual differences in time cause by DCTCP’s slower convergence": "cause by" should be "caused by".
- p. 7 Section 3.5, Convergence and Synchronization
differences in time cause by DCTCP’s slower con-
- p. 7 §3.5 Convergence and Synchronization
the actual differences in time cause by DCTCP’s slower con-
Judge's note: Read on the page 7 image, §3.5 Convergence and Synchronization.
Second check: none (judge only)
Report a problem with this finding
Typo "Simulations show that the convergence times for DCTCP is on the order of 20-30ms": plural subject "times" with singular verb "is".
- p. 7 Section 3.5, Convergence and Synchronization
the convergence times for DCTCP is on the order of
Judge's note: Read on the page 7 image, §3.5. Subject and verb do not agree.
Second check: none (judge only)
Report a problem with this finding
Typo "2 orders of magnitudes less than RTTs in the Internet": should read "orders of magnitude".
- p. 7 §3.5
2 orders of magnitudes less than RTTs in the Internet
Judge's note: Read on the page 7 image, §3.5. The plural "magnitudes" is printed.
Second check: none (judge only)
Report a problem with this finding
Typo "In [32] value of RTOmin was reduced to address the incast problem": article missing before "value".
- p. 9 §4.2.1 Incast
In [32] value of RTOmin was reduced
Judge's note: Read on the page 9 image, §4.2.1.
Second check: none (judge only)
Report a problem with this finding
Typo "DCTCP’s approach of avoiding timeouts, as explained in 3.2.": the section pointer lacks the "§" used for every other section pointer in the paper.
- p. 9 §4.2.1
as explained in 3.2.
- p. 9 4.2.1 Incast
as explained in 3.2
Judge's note: Read on the page 9 image. Other pointers on the same page read "§ 2.3", "§ 2.3.1", "(§ 1)". The target is right: §3.2 Benefits on page 6 has the Incast paragraph. Cosmetic only.
Second check: none (judge only)
Report a problem with this finding
Typo §4.2.3 writes the same incast ratio two ways in adjacent sentences: "participate in a 10-1 incast pattern" and "easily handle 10:1 incast".
- p. 10 §4.2.3
participate in a 10-1 incast pat-
- p. 10 §4.2.3
easily handle 10:1 incast
Judge's note: Read on the page 10 image: both forms are in the typeset text, three lines apart. Notation inconsistency only; the meaning is clear.
Second check: none (judge only)
Report a problem with this finding
Typo §5: "DCTCP, avoids queue buildup, and hence prevents timeouts." has a stray comma between subject and verb.
- p. 12 §5
DCTCP, avoids queue buildup
Judge's note: Page 12 image: the comma after "DCTCP" is in the typeset text ("avoids" is italicised). Cosmetic.
Second check: none (judge only)
Report a problem with this finding
Typo §5: "explicit feedback schemes (e.g., RCP [6], and the ECN-based VCP [34] and BMCC [25]) AQM schemes (e.g., RED [10] and PI [17])." has no comma or "and" between the second and third list items.
- p. 12 §5
BMCC [25]) AQM schemes
Judge's note: Page 12 image: the sentence lists three families (delay-based congestion control, explicit feedback schemes, AQM schemes); the first two are separated by a comma, but "AQM schemes" follows the closing parenthesis directly. Missing separator; cosmetic.
Second check: none (judge only)