From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qg0-x22f.google.com (mail-qg0-x22f.google.com [IPv6:2607:f8b0:400d:c04::22f]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 8AA9121F621; Fri, 7 Aug 2015 06:22:08 -0700 (PDT) Received: by qgeg42 with SMTP id g42so37490277qge.1; Fri, 07 Aug 2015 06:22:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=iXuP3G71KCw0VdFadffaDGdXqNcowe5dwALmaxhhkqU=; b=zDObHrV+GYFqRiySlaOvjzxfDpQKfSXEIZnA4HnRQmhaVFFZx2TiLhKB/r2gF+ZBRe QxbYdvCU9SEGXzzRQopaRml1jayCFuWNdIAHLf2WWGD0Of1T3/8z9X7IpANe457yFKx0 HkTHagcSHeueSTmoYgb8R5u1huP6CHg5k3ymSxZbAlsdUhkd95fp8ly4mmhthwoEyMuh cZ8+d1jLX6POB+jpPqp2SmztaAtHHrzzg6w8AbJXSl1gEc8GpU8NTc1CR5GRo+AyksfU 942wID86Oh5yNjS5V2ReTf/7/eNtS9djVHLRt4dDGWlfT1AQ8k5z6ks7u7i3//Q2pWtv ucIA== X-Received: by 10.141.23.130 with SMTP id z124mr13758112qhd.55.1438953727043; Fri, 07 Aug 2015 06:22:07 -0700 (PDT) Received: from richs-mbp-13907.lan ([71.169.176.121]) by smtp.gmail.com with ESMTPSA id i200sm4885970qhc.33.2015.08.07.06.22.05 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 07 Aug 2015 06:22:06 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Rich Brown In-Reply-To: Date: Fri, 7 Aug 2015 09:22:04 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <356F5FEE-9FBD-4FF9-AC17-86A642D918A4@gmail.com> <5CC1DC90-DFAF-4A4D-8204-16CD4E20D6E3@gmx.de> <4D24A497-5784-493D-B409-F704804326A7@gmx.de> <1438361254.45977158@apps.rackspace.com> To: Mikael Abrahamsson X-Mailer: Apple Mail (2.1878.6) Cc: make-wifi-fast@lists.bufferbloat.net, dpreed@reed.com, cerowrt-devel@lists.bufferbloat.net Subject: Re: [Make-wifi-fast] [Cerowrt-devel] [tsvwg] Comments on draft-szigeti-tsvwg-ieee-802-11e X-BeenThere: make-wifi-fast@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2015 13:22:36 -0000 Here's where I display my massive ignorance of how Linux = networking/drivers work. This feels like a place to apply the Nagle = algorithm... Maybe everyone already understands this, but, isn't this = scheme something like what we're looking for?=20 - Initial state: all queues (fq_codel and wifi driver) are empty. - A packet arrives at fq_codel, it's placed in the proper queue for its = flow, and the wifi driver gets tapped on the shoulder that there's = something to send. - Sometime later, the wifi driver has bid for and received an = opportunity to transmit.=20 - At that time, the wifi driver requests packets from fq_codel until a) = the the fq_codel queues are empty, or b) the wifi frame is full. In = either case, the wifi driver sends what it has. - If more packets remain in the fq_codel queue(s), the wifi driver gets = tapped on the shoulder again to start another transmission.=20 Good Attributes: - The wifi driver has no "queued packets" per se - only those it pulled = from fq_codel for immediate transmission. - Once the transmit opportunity has come around, it's a matter of = microseconds (I assume) to pull in a wifi frame's worth of packets from = fq_codel - A singleton packet (e.g., one widely separated in time from all the = other traffic) gets sent as soon as it can, without waiting in hopes = "that more traffic will arrive" This leaves the wifi utilization = unchanged (since the singleton packet would have to be sent anyway), but = avoids the delay for that particular flow. Downsides: - Most likely, "It doesn't work that way". :-) - The wifi driver would probably have to queue the single last-retrieved = packet from fq_codel when it doesn't fit in the wifi frame. But this = would be an immediate signal to bid for another transmit opportunity. Rich On Aug 7, 2015, at 4:28 AM, Mikael Abrahamsson wrote: > On Fri, 31 Jul 2015, dpreed@reed.com wrote: >=20 >> So ignore the hardware folks who can't think about the fact that = their link is embedded in a context that the link doesn't understand at = all! Don't let them convince you to queue things, especially lower = priority things.... instead push congestion back to the source!!! >=20 > So while I think you have a point, I don't see how this can be = achieved (at most 1 packet in the queue) on something like wifi where = there are retransmits and an onloaded link can have between a few ms and = all of a sudden have 50-100ms of delay, and then get back to a few ms = again). If you screetch to a halt when you get this "congestion" (that = isn't even caused by traffic but by RF environment), if you have packets = in the buffer and feedback the sender to stop, there after the RF = problem has past, buffer is emptied, but now basically all traffic has = screetched to a halt. >=20 > So a compromise must be achieved somewhere, so that 300ms RTT flows = get decent performance without affecting realtime flows. I don't = understand how both goals of low delay/no buffering and decent high-RTT = flow speed, can work without some kind of scheme where different flows = are put in different queues. >=20 > --=20 > Mikael Abrahamsson email: swmike@swm.pp.se > _______________________________________________ > Cerowrt-devel mailing list > Cerowrt-devel@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cerowrt-devel