From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id 5129821F1A4 for ; Thu, 21 Aug 2014 00:12:05 -0700 (PDT) Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1XKMXS-0007sc-Aj; Thu, 21 Aug 2014 09:12:02 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx2.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1XKMXR-0005I0-Oj; Thu, 21 Aug 2014 09:12:02 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Apple Message framework v1283) From: Michael Welzl In-Reply-To: <64CD1035-2E14-4CA6-8E90-C892BAD48EC6@netapp.com> Date: Thu, 21 Aug 2014 09:11:59 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <91696A3A-EF44-4A1A-8070-D3AF25D0D9AC@netapp.com> <64CD1035-2E14-4CA6-8E90-C892BAD48EC6@netapp.com> To: Jim Gettys , bloat , Lars Eggert X-Mailer: Apple Mail (2.1283) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 3 msgs/h 1 sum rcpts/h 4 sum msgs/h 1 total rcpts 19330 max rcpts/h 44 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.1, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-1.051, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 661861F5FB0B9FE4B1A9ECE84D7D41BCADA33CCE X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -60 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 5826 max/h 17 blacklist 0 greylist 0 ratelimit 0 Subject: Re: [Bloat] sigcomm wifi X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 07:12:05 -0000 On 21. aug. 2014, at 08:52, Eggert, Lars wrote: > On 2014-8-21, at 0:05, Jim Gettys wrote: >> =E2=80=8BAnd what kinds of AP's? All the 1G guarantees you is that = your bottleneck is in the wifi hop, and they can suffer as badly as = anything else (particularly consumer home routers). >>=20 >> The reason why 802.11 works ok at IETF and NANOG is that: >> o) they use Cisco enterprise AP's, which are not badly over = buffered. I'd like to better understand this particular bloat problem: 100s of senders try to send at the same time. They can't all do that, so = their cards retry a fixed number of times (10 or something, I don't = remember, probably configurable), for which they need to have a buffer. Say, the buffer is too big. Say, we make it smaller. Then an 802.11 = sender trying to get its time slot in a crowded network will have to = drop a packet, requiring the TCP sender to retransmit the packet = instead. The TCP sender will think it's congestion (not entirely wrong) = and reduce its window (not entirely wrong either). How appropriate TCP's = cwnd reduction is probably depends on how "true" the notion of = congestion is ... i.e. if I can buffer only one packet and just don't = get to send it, or it gets a CRC error ("collides" in the air), then = that can be seen as a pure matter of luck. Then I provoke a sender = reaction that's like the old story of TCP mis-interpreting random losses = as a sign of congestion. I think in most practical systems this old = story is now a myth because wireless equipment will try to buffer data = for a relatively long time instead of exhibiting sporadic random drops = to upper layers. That is, in principle, a good thing - but buffering too = much has of course all the problems that we know. Not an easy trade-off = at all I think. I have two questions: 1) is my characterization roughly correct? 2) have people investigated the downsides (negative effect on TCP) of = buffering *too little* in wireless equipment? (I suspect so?) Finding = where "too little" begins could give us a better idea of what the ideal = buffer length should really be. Cheers, Michael