From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from bifrost.lang.hm (mail.lang.hm [64.81.33.126]) (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 09A9321F30B for ; Sun, 31 Aug 2014 15:37:18 -0700 (PDT) Received: from asgard.lang.hm (asgard.lang.hm [10.0.0.100]) by bifrost.lang.hm (8.13.4/8.13.4/Debian-3) with ESMTP id s7VMb7mh003509; Sun, 31 Aug 2014 15:37:07 -0700 Date: Sun, 31 Aug 2014 15:37:07 -0700 (PDT) From: David Lang X-X-Sender: dlang@asgard.lang.hm To: Sebastian Moeller In-Reply-To: Message-ID: References: <91696A3A-EF44-4A1A-8070-D3AF25D0D9AC@netapp.com> <64CD1035-2E14-4CA6-8E90-C892BAD48EC6@netapp.com> <4C1661D0-32C6-48E7-BAE6-60C98D7B2D69@ifi.uio.no> <8C18A920-D0A8-4052-85EC-FF6D6039FD53@ifi.uio.no> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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: Sun, 31 Aug 2014 22:37:18 -0000 On Mon, 25 Aug 2014, Sebastian Moeller wrote: > Hi Michael, > > On Aug 25, 2014, at 10:01 , Michael Welzl wrote: > [...] >> >>> This is a case where a local proxy server can actually make a big difference >>> to you. The connections between your mobile devices and the local proxy >>> server have a short RTT and so all timeouts can be nice and short, and then >>> the proxy deals with the long RTT connections out to the Internet. >> >> Adding a proxy to these considerations only complicates them: it's a hard >> enough trade-off when we just ask ourselves: how large should a buffer for >> the sake of link layer retransmissions be? (which is closely related to the >> question: how often should a link layer try to retransmit before giving up?) >> That's what my emails were about. I suspect that we don't have a good answer >> to even these questions, and I suspect that we'd better off having something >> dynamic than fixed default values. > > What about framing the retransmissions not in number but rather in time? > For example the maximum of either time to transmit a few (say 3?) packet at > the current data rate (or maybe one rate lower than current to allow > setoriating signal quality) or 20ms (pulled out of thin air, would need some > research). The first should make sure we actually retransmit to overcome > glitches, and the second should make sure that RTT does not increase to > dramatically. This basically assumes that for reasonable interactive traffic > we only have a given RTT budget and should make sure not to overspend ;) Yep, just like BQL helped a lot on the wired side, because it's a good stand-in for the time involved, we need to get the same concept through the wifi stack and drivers. David Lang