From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) (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 7CC7021F783 for ; Fri, 29 Aug 2014 23:06:04 -0700 (PDT) Received: by mail-la0-f49.google.com with SMTP id b17so3775420lan.36 for ; Fri, 29 Aug 2014 23:06:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=WGrlnbam/BqKWsLETFi7WXmnst2JCo1pgIgJoKIOt3I=; b=0KVf1iMwp+b2IPAtFtVgOawLhbQXv5d1HqreAa7xrhK/rs/IYOktfsDwndcrPz91Sp ZitH8gog22c+JtjXY4hw3TFkgxM3/v43Nf4oRUXt0JUV9w3kKSN8RICu+e6xYXYhDsRA sm0LLDEPfiUeVAInuyzg7NtV56YWA8QJbPoyfxtkIQMOqioFNxsBjMTkxXfWj6BmJjHy /mfzQhjR58VWZdfy5AqDi1n1+GLFkJfp8KbihofgSq/P991ecvLyQusgTKBjrgKMyENT NI/UxnJzPFahyHnhQohoePw/37OkoFQJlsPwJhmuAT8qaCFiNp3vaUrpJzmE3zNA82Qw X5OA== X-Received: by 10.152.30.100 with SMTP id r4mr297675lah.87.1409378761653; Fri, 29 Aug 2014 23:06:01 -0700 (PDT) Received: from bass.home.chromatix.fi (188-67-224-93.bb.dnainternet.fi. [188.67.224.93]) by mx.google.com with ESMTPSA id e2sm1276154laa.44.2014.08.29.23.05.59 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 29 Aug 2014 23:06:00 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Jonathan Morton In-Reply-To: <002a01cfc396$ba5c8510$2f158f30$@duckware.com> Date: Sat, 30 Aug 2014 09:05:58 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <569E96E0-297C-4895-B402-F2B55E1953FA@gmail.com> References: <000001cfbefe$69194c70$3b4be550$@duckware.com> <000901cfc2c2$c21ae460$4650ad20$@duckware.com> <4A89264B-36C5-4D1F-9E5E-33F2B42C364E@gmail.com> <002201cfc2e4$565c1100$03143300$@duckware.com> <002a01cfc396$ba5c8510$2f158f30$@duckware.com> To: "Jerry Jongerius" X-Mailer: Apple Mail (2.1085) Cc: bloat@lists.bufferbloat.net Subject: Re: [Bloat] The Dark Problem with AQM in the Internet? 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: Sat, 30 Aug 2014 06:06:05 -0000 On 29 Aug, 2014, at 5:37 pm, Jerry Jongerius wrote: >> did you check to see if packets were re-sent even if they weren't = lost? on of >> the side effects of excessive buffering is that it's possible for a = packet to >> be held in the buffer long enough that the sender thinks that it's = been >> lost and retransmits it, so the packet is effectivly 'lost' even if = it actually >> arrives at it's destination. >=20 > Yes. A duplicate packet for the missing packet is not seen. >=20 > The receiver 'misses' a packet; starts sending out tons of dup acks = (for all > packets in flight and queued up due to bufferbloat), and then way = later, the > packet does come in (after the RTT caused by bufferbloat; indicating = it is > the 'resent' packet). =20 I think I've cracked this one - the cause, if not the solution. Let's assume, for the moment, that Jerry is correct and PowerBoost plays = no part in this. That implies that the flow is not using the full = bandwidth after the loss, *and* that the additive increase of cwnd isn't = sufficient to recover to that point within the test period. There *is* a sequence of events that can lead to that happening: 1) Packet is lost, at the tail end of the bottleneck queue. 2) Eventually, receiver sees the loss and starts sending duplicate acks = (each triggering CA_EVENT_SLOW_ACK path in the sender). Sender (running = Westwood+) assumes that each of these represents a received, full-size = packet, for bandwidth estimation purposes. 3) The receiver doesn't send, or the sender doesn't receive, a duplicate = ack for every packet actually received. Maybe some firewall sees a = large number of identical packets arriving - without SACK or timestamps, = they *would* be identical - and filters some of them. The bandwidth = estimate therefore becomes significantly lower than the true value, and = additionally the RTO fires and causes the sender to reset cwnd to 1 = (CA_EVENT_LOSS). 4) The retransmitted packet finally reaches the receiver, and the ack it = sends includes all the data received in the meantime (about 3.5MB). = This is not sufficient to immediately reset the bandwidth estimate to = the true value, because the BWE is sampled at RTT intervals, and also = includes low-pass filtering. 5) This ends the recovery phase (CA_EVENT_CWR_COMPLETE), and the sender = resets the slow-start threshold to correspond to the estimated = delay-bandwidth product (MinRTT * BWE) at that moment. 6) This estimated DBP is lower than the true value, so the subsequent = slow-start phase ends with the cwnd inadequately sized. Additive = increase would eventually correct that - but the key word is = *eventually*. - Jonathan Morton