From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (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 ABA0421FD3E; Fri, 7 Aug 2015 01:28:44 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id B03B8A1; Fri, 7 Aug 2015 10:28:39 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1438936119; bh=a9cMfSnk0+3L3t08r0lFZam24XN6yAbOh1oo/jv4WwI=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=oo6vn/PDRAOCcwcSP6AYiGnpIbIfKGlJCq8A4pOGu9wMqyEahUBGmsYRxcfSHwJhO xBYsWNGJVLNj/KQT6euy+R0/X2U7u0qfYRbVTHn95iuo5oI0QOoaN5GuQJ6Rc/xoCz epDmKTFTMLiMCqBtvR8U1QozvI1Z0UHojNrdzfVg= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id A9A919F; Fri, 7 Aug 2015 10:28:39 +0200 (CEST) Date: Fri, 7 Aug 2015 10:28:39 +0200 (CEST) From: Mikael Abrahamsson To: dpreed@reed.com In-Reply-To: <1438361254.45977158@apps.rackspace.com> 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> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Sat, 08 Aug 2015 08:27:43 -0700 Cc: make-wifi-fast@lists.bufferbloat.net, 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 08:29:13 -0000 On Fri, 31 Jul 2015, dpreed@reed.com wrote: > 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!!! 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. 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. -- Mikael Abrahamsson email: swmike@swm.pp.se