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