From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) (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 A830A21F34D for ; Fri, 22 Aug 2014 16:07:24 -0700 (PDT) Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1XKxvU-0004LY-3k; Sat, 23 Aug 2014 01:07:20 +0200 Received: from modgunn.ext.hb.se ([193.11.73.8] helo=[10.10.18.108]) by mail-mx1.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1XKxvT-0007va-9N; Sat, 23 Aug 2014 01:07:20 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Michael Welzl In-Reply-To: Date: Sat, 23 Aug 2014 01:07:11 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4C1661D0-32C6-48E7-BAE6-60C98D7B2D69@ifi.uio.no> References: <91696A3A-EF44-4A1A-8070-D3AF25D0D9AC@netapp.com> <64CD1035-2E14-4CA6-8E90-C892BAD48EC6@netapp.com> To: David Lang X-Mailer: Apple Mail (2.1878.2) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 4 msgs/h 1 sum rcpts/h 8 sum msgs/h 2 total rcpts 19437 max rcpts/h 44 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: CF2D70824E8DE4849A6BF1D6101292EC2D92FAC4 X-UiO-SPAM-Test: remote_host: 193.11.73.8 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 3 max/h 2 blacklist 0 greylist 0 ratelimit 0 Cc: bloat 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: Fri, 22 Aug 2014 23:07:24 -0000 On 21. aug. 2014, at 10:30, David Lang wrote: > On Thu, 21 Aug 2014, Michael Welzl wrote: >=20 >> On 21. aug. 2014, at 08:52, Eggert, Lars wrote: >>=20 >>> 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). >>>> 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. >>=20 >> I'd like to better understand this particular bloat problem: >>=20 >> 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. >>=20 >> 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. >=20 > in this case the loss is a direct sign of congestion. "this case" - I talk about different buffer lengths. E.g., take the = minimal buffer that would just function, and set retransmissions to 0. = Then, a packet loss is a pretty random matter - just because you and I = contended, doesn't mean that the net is truly "overloaded" ? So my = point is that the buffer creates a continuum from "random loss" to = "actual congestion" - we want loss to mean "actual congestion", but how = large should it be to meaningfully convey that? > remember that TCP was developed back in the days of 10base2 networks = where everyone on the network was sharing a wire and it was very = possible for multiple senders to start transmitting on the wire at the = same time, just like with radio. cable or wireless: is one such occurrence "congestion"? i.e. is halving the cwnd really the right response to that sort of = "congestion"? (contention, really) > A large part of the problem with high-density wifi is that it just = wasn't designed for that sort of environment, and there are a lot of = things that it does that work great for low-density, weak signal = environments, but just make the problem worse for high-density = environements >=20 > batching packets together > slowing down the transmit speed if you aren't getting through well... this *should* only happen when there's an actual physical signal = quality degradation, not just collisions. at least minstrel does quite a = good job at ensuring that, most of the time. > retries of packets that the OS has given up on (including the user has = closed the app that sent them) >=20 > Ideally we want the wifi layer to be just like the wired layer, buffer = only what's needed to get it on the air without 'dead air' (where the = driver is waiting for the OS to give it more data), at that point, we = can do the retries from the OS as appropriate. >=20 >> 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. >=20 > too little buffering will reduce the throughput as a result of unused = airtime. so that's a function of, at least: 1) incoming traffic rate; 2) no. = retries * ( f(MAC behavior; number of other senders trying) ). > But at the low data rates involved, the system would have to be = extremely busy to be a significant amount of time if even one packet at = a time is buffered. > You are also conflating the effect of the driver/hardware buffering = with it doing retries. because of the "function" i wrote above: the more you retry, the more = you need to buffer when traffic continuously arrives because you're = stuck trying to send a frame again. what am I getting wrong? this seems to be just the conversation I was = hoping to have ( so thanks!) - I'd like to figure out if there's a = fault in my logic. Cheers, Michael