Hi Mikael, the papers around DCTCP have probably the information you are looking for (map/reduce type workloads, leading to incast issues - momentary filling of queues; loosing the final segments of a TCP session [1], which is likely with drop tail queue management policy, is well known to result in timely retransmission timeout-type recoveries. Tweaking OS time granularities down to recover in few milliseconds on paths that usually have a few dozen microseconds delay is often not good enough, but even that is not for cautious.
Apparently, this is seen important and valuable enough to motivate the unilateral deployment of DCTCP with Windows 8 server, even though the modification in the switches is then still necessary. Richard Scheffenegger [1] Google has presented the liklihood of packet loss per segment vs. burst size; Figure 3 in this paper http://plus.url.google.com/url?sa=z&n=1380288903097&url=http%3A%2F%2Fstatic.googleusercontent.com%2Fexternal_content%2Funtrusted_dlcp%2Fresearch.google.com%2Fen%2F%2Fpubs%2Farchive%2F41217.pdf&usg=lEiaJfELSWQoGNsDNsbQgbSO9RQ. > -----Original Message----- > From: Mikael Abrahamsson [mailto:[email protected]] > Sent: Freitag, 27. September 2013 04:59 > To: Scheffenegger, Richard > Cc: [email protected]; [email protected]; bloat > Subject: RE: [iccrg] [aqm] [Bloat] AQM deployment status? > > On Thu, 26 Sep 2013, Scheffenegger, Richard wrote: > > > I'd state that people operating datacenters with request-response type > > data exchange via TCP do care a lot about the microscopic drop > > distribution. Typically, a tail-drop queue has the unfortunate > > property of losing the more critical packets of such an exchange, > > leading to excessive "transaction" (higher level protocol) delays due > > to lengthy TCP loss recovery. > > Do you know of simulations or similar that investigates this? I would like > to understand why having RED on a 3ms buffer depth device makes a > difference and how much difference it makes. > > -- > Mikael Abrahamsson email: [email protected] _______________________________________________ aqm mailing list [email protected] https://www.ietf.org/mailman/listinfo/aqm
