Bertha & M Sadeeq






Easy to manage the problems
Scalability
Real time and real environment
Free data collection
Cost efficient
DCTCP only covers
◦ High burst tolerance
◦ Low latency
◦ High performance



They worked on commodity switches (Shallow
buffered) with 6000 servers while the data speed
up-to 10Gbps.
Low cost switches at the top of the rack providing
48 ports at 1 Gbps.
They find DCTCP deliver the same or better
throughput then TCP.



Unlike TCP, DTCP provide high burst tolerance
and low latency for short flow.
Many applications find it difficult to meet the
deadlines using state-of-the-art TCP, our
applications carefully controls the amount of data
each worker send and adds jitter .
They only measure and analyze compressed
data(>150TB).

Lets assume their system is OK…
They are working in homogenous, single
controlled environment but they did not discuss
◦ Backward compatibility
◦ Incremental deployment



F -Fraction of packets marked
α -Senders record of marked packets
g – might be the weight on the basis of past Pkt marked
0<g<1
Totally RED marking idea already used in TCP and they
accepted the fact by implementing it like…..
When α=1 DCTCP cuts window in half, just like TCP.
So….???

They assuming N flows are synchronized. For this
equation….
-Using the idea of cut window from TCP (for W (t)).
-Single bottle neck capacity (C).
-Identical round trip time (RTT).
So I think your problem is solved…huh!


Based on workload inside a homogenous data
center and does not take into account variable
receiver/sender buffers or the co-existence of
other protocols.
Is existing hardware able to reproduce these
results?
◦ Explicitly mentions a Broadcom Triumph, Broadcom
Scorpion, and Cisco CAT4948 switch, but what is the real
availability of a switch to support ECN?


ECN was mentioned but no measurements
were performed contrasting DCTCP with plain
TCP with ECN.
All comparisons are made to a TCP New Reno
(w/SACK) implementation.
◦ Is this representative of what most DC’s currently use?

Single bottle-neck used for evaluation

“DCTCP trades off convergence time” in order
to achieve its goals (sec 3.5)

DCTCP converges quickly (sec 4.1)

Don't you think it is conflicting with the goal?

The paper talks about separating DCTCP
flows from TCP flows to improve
performance, but it is not clear how this may
be done when external traffic is included.


The analysis previous section is for idealized DCTCP
source, and does not capture any of the burstiness
inherent to actual implementation of window-based
congestion control protocols in the network stack.
Even in performance when k>65 then DCTCP=TCP,
so?


Graphs not on the same page they were
referenced.
Estimation gain, g :
◦ Sec 3.1 – “the weight given to new samples against
the past in the estimation of” alpha
◦ Two pgs later, sec 3.4 - randomly labeled
“estimation gain”

This paper suggested no future work…


Has only been cited 9 times…
One of which is their follow up to this paper,
analyzing DCTCP
◦ Conclusion: “Our analysis shows that DCTCP can
achieve very high throughput while maintaining low
buffer occupancies.”
…Sound familiar?