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 921D721F3B1 for ; Mon, 25 Aug 2014 01:34:01 -0700 (PDT) Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1XLpiw-0005n2-JL; Mon, 25 Aug 2014 10:33:58 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx4.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1XLpiw-00074k-5N; Mon, 25 Aug 2014 10:33:58 +0200 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Michael Welzl In-Reply-To: Date: Mon, 25 Aug 2014 10:33:57 +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: Sebastian Moeller X-Mailer: Apple Mail (2.1283) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 10 msgs/h 3 sum rcpts/h 16 sum msgs/h 5 total rcpts 19478 max rcpts/h 44 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.0, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-1.05, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 1E6F42670D6A0E4D8AF0368DD6CC6E2A592D31A0 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -59 maxlevel 80 minaction 2 bait 0 mail/h: 3 total 5875 max/h 17 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: Mon, 25 Aug 2014 08:34:01 -0000 On 25. aug. 2014, at 10:19, Sebastian Moeller wrote: > Hi Michael, >=20 > 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. >=20 > 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 ;) That would be VERY good I think!!!! As for the actual recommendations, I think we'll also need a lower = minimum to avoid that a single random collision that has nothing to do = with any real overload causes a TCP reaction. THAT number could be 3, = for example. Then, we typically have a default value of retransmissions in today's = equipment - I think that number is usually something in the order of 10. = So yes, that limit could be replaced with something like "min(10 = retransmissions, 20ms)". I actually wonder what magnitude we can really = reach in a practical system - e.g., is 20ms way beyond realistic in a = super crowded network? Worth analyzing I guess. Cheers, Michael