General list for discussing Bufferbloat
 help / color / mirror / Atom feed
From: "Scheffenegger, Richard" <rs@netapp.com>
To: Mikael Abrahamsson <swmike@swm.pp.se>
Cc: "iccrg@irtf.org" <iccrg@irtf.org>, "aqm@ietf.org" <aqm@ietf.org>,
	bloat <bloat@lists.bufferbloat.net>
Subject: Re: [Bloat] [iccrg] [aqm]    AQM deployment status?
Date: Fri, 27 Sep 2013 13:53:21 +0000	[thread overview]
Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F25D969C5@SACEXCMBX02-PRD.hq.netapp.com> (raw)
In-Reply-To: <alpine.DEB.2.02.1309270456370.32315@uplift.swm.pp.se>

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:swmike@swm.pp.se]
> Sent: Freitag, 27. September 2013 04:59
> To: Scheffenegger, Richard
> Cc: iccrg@irtf.org; aqm@ietf.org; 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: swmike@swm.pp.se

  parent reply	other threads:[~2013-09-27 13:53 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-24 17:21 [Bloat] " Naeem Khademi
2013-09-24 17:24 ` [Bloat] [aqm] " LOCHIN Emmanuel
2013-09-25 14:20 ` Akhtar, Shahid (Shahid)
2013-09-25 14:31   ` [Bloat] [iccrg] " Eggert, Lars
2013-09-25 14:35     ` Steinar H. Gunderson
2013-09-25 18:51       ` Akhtar, Shahid (Shahid)
2013-09-25 19:19         ` [Bloat] [aqm] [iccrg] " Naeem Khademi
2013-09-27 16:49           ` Akhtar, Shahid (Shahid)
2013-09-25 19:24         ` Mikael Abrahamsson
2013-09-26  9:39           ` [Bloat] [iccrg] [aqm] " Scheffenegger, Richard
2013-09-27  2:59             ` Mikael Abrahamsson
2013-09-27  9:06               ` Eggert, Lars
2013-09-28  7:01                 ` Mikael Abrahamsson
2013-09-28  7:04                   ` Eggert, Lars
2013-09-29  1:16                     ` [Bloat] [aqm] [iccrg] " Bob Briscoe
2013-09-29  9:37                       ` Mikael Abrahamsson
2013-09-27 13:53               ` Scheffenegger, Richard [this message]
2013-09-28  6:59                 ` [Bloat] [iccrg] [aqm] " Mikael Abrahamsson
2013-11-13 17:50           ` [Bloat] [aqm] [iccrg] " Fred Baker (fred)
2013-10-12  3:18     ` [Bloat] [iccrg] [aqm] " Michael Richardson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.bufferbloat.net/postorius/lists/bloat.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=012C3117EDDB3C4781FD802A8C27DD4F25D969C5@SACEXCMBX02-PRD.hq.netapp.com \
    --to=rs@netapp.com \
    --cc=aqm@ietf.org \
    --cc=bloat@lists.bufferbloat.net \
    --cc=iccrg@irtf.org \
    --cc=swmike@swm.pp.se \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox