From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-vn0-x229.google.com (mail-vn0-x229.google.com [IPv6:2607:f8b0:400c:c0f::229]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 5C99121F55F for ; Thu, 4 Jun 2015 13:01:47 -0700 (PDT) Received: by vnbg7 with SMTP id g7so437883vnb.10 for ; Thu, 04 Jun 2015 13:01: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:date:message-id:subject:from:to :cc:content-type; bh=y+otruuOk4retUNWo/6L6k380UWfjgECVUph6DJOUUc=; b=q6iRKG4mpD8uesCawp1hL0SUNWNvuNJ7vwwBxzI5oV23KUbj62RxQQjm5N6QHzk6fC 8Ek17SRMEFfCaO7r7DZqBTsXi3kQe1mKSW+6WO93d1SDgVc70BQHH/0K0cMKDjtU7uBo fb78640sEKnZuzj8sw2LxI+53rwVchYHb36aVSoLK2ALWFbnwZpgAO7uEt6zAqC5HPn5 ArDZ+Rmq3u/HkJ/ADb2a5/PexTK6y6BQrE/h8YGbyN45RLf5sTSDiabG3GE0+i7UOYpD lDLZIpeZviwvNjCWxeV+hZfGZQhVxwYy9IYsu0FJlehBqwW0DpGfiiFU+l/rB9PZly/+ wb3w== MIME-Version: 1.0 X-Received: by 10.52.136.9 with SMTP id pw9mr10553512vdb.44.1433448106681; Thu, 04 Jun 2015 13:01:46 -0700 (PDT) Received: by 10.52.12.167 with HTTP; Thu, 4 Jun 2015 13:01:46 -0700 (PDT) Received: by 10.52.12.167 with HTTP; Thu, 4 Jun 2015 13:01:46 -0700 (PDT) In-Reply-To: <7D4DDC3F-9233-4E07-B59B-AA1368CA9D4E@gmail.com> References: <7D4DDC3F-9233-4E07-B59B-AA1368CA9D4E@gmail.com> Date: Thu, 4 Jun 2015 23:01:46 +0300 Message-ID: From: Jonathan Morton To: Rich Brown Content-Type: multipart/alternative; boundary=bcaec52e658b33ed680517b6a502 Cc: bloat Subject: Re: [Bloat] Bloat goes away, but with ~25% speed loss? 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: Thu, 04 Jun 2015 20:02:16 -0000 --bcaec52e658b33ed680517b6a502 Content-Type: text/plain; charset=UTF-8 I think he may be seeing a complex interaction of various different queue components and bottlenecks, which in total manages to confuse TCP congestion control sufficiently to cause reduced throughput. I suspect that there is a shaper at the ISP end which limits the bandwidth available to any single subscriber. This is separate from the queue serving the tower itself, which is what has been admitted to be periodically overloaded. However, "overloaded" in network engineer parlance just means a multi-user link that is saturated. There might well be enough elasticity to allow one subscriber their full allocation by pushing others out of the way. In this condition, the tower queue will be full and so will the shaper queue. I imagine the shaper queue contributes the most to induced latency. However, this "pushing others out of the way" on a drop-tail queue is done by allowing the congestion window to grow to large values, facilitated by the deep ISP shaper queue. This effect is defeated (by design) by running an ingress AQM shaper, which keeps the ISP shaper queue empty. A useful exercise might be to log the idle latency over a long period of time, and correlate it to peak load periods, as A&A do. http://aa.net.uk/kb-broadband-cqm.html . - Jonathan Morton --bcaec52e658b33ed680517b6a502 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I think he may be seeing a complex interaction of various di= fferent queue components and bottlenecks, which in total manages to confuse= TCP congestion control sufficiently to cause reduced throughput.

I suspect that there is a shaper at the ISP end which limits= the bandwidth available to any single subscriber. This is separate from th= e queue serving the tower itself, which is what has been admitted to be per= iodically overloaded. However, "overloaded" in network engineer p= arlance just means a multi-user link that is saturated. There might well be= enough elasticity to allow one subscriber their full allocation by pushing= others out of the way. In this condition, the tower queue will be full and= so will the shaper queue. I imagine the shaper queue contributes the most = to induced latency.

However, this "pushing others out of the way" on a= drop-tail queue is done by allowing the congestion window to grow to large= values, facilitated by the deep ISP shaper queue. This effect is defeated = (by design) by running an ingress AQM shaper, which keeps the ISP shaper qu= eue empty.

A useful exercise might be to log the idle latency over a lo= ng period of time, and correlate it to peak load periods, as A&A do. http://aa.net.uk/kb-broadb= and-cqm.html .

- Jonathan Morton

--bcaec52e658b33ed680517b6a502--