From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-1" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 5D39121F3B1 for ; Mon, 25 Aug 2014 01:19:58 -0700 (PDT) Received: from u-089-csam313b.am5.uni-tuebingen.de ([134.2.89.14]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0Lhwgc-1WYhAm2kni-00nBBv; Mon, 25 Aug 2014 10:19:54 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sebastian Moeller In-Reply-To: <8C18A920-D0A8-4052-85EC-FF6D6039FD53@ifi.uio.no> Date: Mon, 25 Aug 2014 10:19:51 +0200 Content-Transfer-Encoding: quoted-printable 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> To: Michael Welzl X-Mailer: Apple Mail (2.1878.6) X-Provags-ID: V03:K0:UEwHySrG1em8NycmlNwmy/4T4+KBlQqnTpLFojyqIqOeLDF6D0w bliL6dBPKxsi9+mqQlnLtXSo/2/NvyQkJSCjwdjXVf1DUVyr9kvZghOWwndTsHASXEiV/c6 Bys5LU3fhkH1331n7xTDdKck6tU6RksKbKaTeHe8NN9BZAp2j5SNLl+Emm3vWxmS1tBqLw8 vF/jdy1yc5t+mzmBOIFlQ== X-UI-Out-Filterresults: notjunk:1; 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: Mon, 25 Aug 2014 08:19:58 -0000 Hi Michael, On Aug 25, 2014, at 10:01 , Michael Welzl wrote: [...] >=20 >> 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. >=20 > 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 ;) Best Reards Sebastian >=20 > Cheers, > Michael >=20 > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat