From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-vk0-x22b.google.com (mail-vk0-x22b.google.com [IPv6:2607:f8b0:400c:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 2BE233B25E for ; Sat, 15 Oct 2016 01:35:46 -0400 (EDT) Received: by mail-vk0-x22b.google.com with SMTP id b186so133896156vkb.1 for ; Fri, 14 Oct 2016 22:35:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=in9yBCIM928cY/03jj7oyatxBFQR6ipWVRBcvRsh2xU=; b=VlFpE4cFDKGJJC1mXTSAFAGBQ30rEqryHrTi3ArK/oW100Vjq+3VJ0kDBUoFR2s8ya s+xN97JYyhT2kf0lgSEiF++BXOt4lETbEvAhby74BjhaVzS/JkVDlEKl5HCh8rvfwK6J 7KasgWCtuVsh1mHLrXyDZHFaHGGlbocZsiT5HV8u0F6PvHPkyaIUBYvPAUlXVRRPR7Is kpdLK21H1FKubQUV3ft7YmqYyhCJNT2EV3h8UtEsRNZGi7Oarulvgu0UYzGMuu+XOdLX RFro1NJ7QL3bYDQDbKicY/TWH4Aas3jLobiVf29LOEgxUU9NfP4RnyhK5muadNVCk6c5 81AQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=in9yBCIM928cY/03jj7oyatxBFQR6ipWVRBcvRsh2xU=; b=bFswU0fY9QBcYy4aKp2MYy5DmaNOEcXbnUyE/nkHvXKWmVOotBfJpMXPdELwobcMpH 39DoqfodLE2+wb6/8V2u/jK+xKXMOskww1bFhg25cmLz9Vatw4tF0jUMiYa8a7GqvPD/ ou/xu4Ij0/aOEQXeUacVJwzzfu4a4Z+kTfW8H/L/MiLp4rtf/sbYO0REwIzEofVITDia h8p+El7iKsryGAX+mhpcNYo7uyyOuu6fLenYqG7mkTFOLJrVAD1EKvs1wV//Bp3g9x8w +QjZoKLZKjNtQyqhl4a0Gec+od4D8vO2l9bWPJrTU72b1qVJzwO4d5CgKyFzDtSk2FNy FFtA== X-Gm-Message-State: AA6/9RkMA4mUP1+xB6BwI3x0AtQv+PG/G8Lx6X3/eNPNi0cqPRh2FFWDmue0sjM2iHG7dNavS0LhI45+LHmm4w== X-Received: by 10.31.227.129 with SMTP id a123mr11996614vkh.65.1476509745710; Fri, 14 Oct 2016 22:35:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.37.7 with HTTP; Fri, 14 Oct 2016 22:35:44 -0700 (PDT) Received: by 10.159.37.7 with HTTP; Fri, 14 Oct 2016 22:35:44 -0700 (PDT) In-Reply-To: References: From: Jonathan Morton Date: Sat, 15 Oct 2016 08:35:44 +0300 Message-ID: To: jb Cc: Dave Taht , bloat Content-Type: multipart/alternative; boundary=001a114da690e68c05053ee0b631 Subject: Re: [Bloat] grading bloat better X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Oct 2016 05:35:46 -0000 --001a114da690e68c05053ee0b631 Content-Type: text/plain; charset=UTF-8 Yes, it looks like typical head-of-line blocking with a multi-second buffer. To smooth it out, you would need an averaging window wider than the effective (bloated) RTT. A tell-tale symptom is that the width of the gap, in which little or no progress is made at the application layer, is approximately the measured RTT at the left edge of the valley (or, equivalently, the peak RTT). It takes that long for the retransmitted packets to traverse the stuffed queue, even though the sender also reduces its send rate at the same time. The latter should cause the RTT to reduce somewhat after the right edge of the valley - this is part of the classic sawtooth. Another tell-tale is therefore that the valleys are regularly spaced on a lengthened test, though there are other possible causes of that. Your user should be able to reproduce the effect on a big, single stream download, by watching the progress and noting that it periodically stalls and then jumps ahead. The average progress rate remains 50Mbps, but the instantaneous progress rate regularly falls to zero. I do suggest that you try to detect this case and explain the above facts automatically. - Jonathan Morton --001a114da690e68c05053ee0b631 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Yes, it looks like typical head-of-line blocking with a mult= i-second buffer.=C2=A0 To smooth it out, you would need an averaging window= wider than the effective (bloated) RTT.

A tell-tale symptom is that the width of the gap, in which l= ittle or no progress is made at the application layer, is approximately the= measured RTT at the left edge of the valley (or, equivalently, the peak RT= T). It takes that long for the retransmitted packets to traverse the stuffe= d queue, even though the sender also reduces its send rate at the same time= .

The latter should cause the RTT to reduce somewhat after the= right edge of the valley - this is part of the classic sawtooth.=C2=A0 Ano= ther tell-tale is therefore that the valleys are regularly spaced on a leng= thened test, though there are other possible causes of that.

Your user should be able to reproduce the effect on a big, s= ingle stream download, by watching the progress and noting that it periodic= ally stalls and then jumps ahead.=C2=A0 The average progress rate remains 5= 0Mbps, but the instantaneous progress rate regularly falls to zero.

I do suggest that you try to detect this case and explain th= e above facts automatically.

- Jonathan Morton

--001a114da690e68c05053ee0b631--