From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::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 BE26921F291 for ; Sun, 29 Mar 2015 02:09:09 -0700 (PDT) Received: by lahp7 with SMTP id p7so78907260lah.2 for ; Sun, 29 Mar 2015 02:09:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Y95e849uAz1ID+19Ru9RmoVCMgp2jCflY8htqQYC+eo=; b=rKbF6v8D5Gg6y1j0pCDXkpVfEPCJHTHBmgd0FnZ+jvATF9fAHqwBCb6LD8H7lGrDnO ZVgXTzztUc6ijC0KmBrUx+lZx6eeIG9/P+Of7WaRoXcB5pMczSCkws3O4Wnn1/q6rwP7 ZY38HyMor25FMGDHPtHoew7CcVoXvcXCbVS8ZuWK6XDKGvpBjfth0YA3ixBQhBwicKvb GeZjXj/pQ5rOkyZWTeBLHOcypleora0QpFFLd6RYaNss4f/jsZX4F2jJGC5T3brws7Tt qWltncpx4r4W2W1n162Ar/5urGe0qAQc5gV0qkh750mYj23xOADa0Qhq6CpFHT4O687W nCeA== X-Received: by 10.112.26.43 with SMTP id i11mr24231359lbg.83.1427620147305; Sun, 29 Mar 2015 02:09:07 -0700 (PDT) Received: from bass.home.chromatix.fi (87-95-163-98.bb.dnainternet.fi. [87.95.163.98]) by mx.google.com with ESMTPSA id o8sm1344784lao.37.2015.03.29.02.09.05 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 29 Mar 2015 02:09:06 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Jonathan Morton In-Reply-To: Date: Sun, 29 Mar 2015 12:09:03 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <5BD9D41C-9631-4BD0-9C18-7909E9D6E9C0@gmail.com> References: To: sahil grover X-Mailer: Apple Mail (2.2070.6) Cc: bloat@lists.bufferbloat.net Subject: Re: [Bloat] Requirements for bufferbloat to occur 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: Sun, 29 Mar 2015 09:09:38 -0000 > On 29 Mar, 2015, at 11:04, sahil grover = wrote: >=20 > (1) All say bufferSize should be set very large for bufferbloat to = occur. > =20 > But how much large?? is there any condition? There=E2=80=99s a clue in the name: if the buffer is significantly = larger than it needs to be (and is unmanaged), we call that bufferbloat. If the buffer is too small to absorb a typical burst of packets, the = resulting increase in packet loss will cause a reduction in throughput. = The correct size for an unmanaged buffer is typically the = delay-bandwidth product, which enables it to absorb a transitory burst = from a single TCP flow. However, determining the delay is difficult a priori, and frequently = differs substantially between different flows on the same connection. = So we usually make some reasonable assumption about the delay component = of that formula: 100ms is typical for a broadband connection to the = public Internet, and VoIP can just-about cope with that in practice. Or, to put it another way - if the buffer *induces* significantly more = than 100ms delay under load, that is bufferbloat. > (2) even after setting buffersize very very large, if packets get = dropped due to buffer =20 > overflow when heavy traffic is there. >=20 > is it bufferbloat? Yes. Packet loss has nothing to do with it - it=E2=80=99s the induced = delay that matters. > sholud we take care that maximum limit of buffersize is never reached = and no=20 > packet drop is there due to queue overlow for bufferbloat condition? Extremely large buffers are usually the result of hardware engineers = naively attempting to achieve zero packet loss, by providing buffers = larger than the TCP receive window size. (That is a futile goal - rwnd = is unlimited in modern operating systems which support window scaling.) = However, zero packet loss is not a necessary condition. AQMs often deliberately drop packets in order to signal congestion to = the endpoints. Under some circumstances, this can actually result in = less overall packet loss than on an unmanaged buffer. Even without ECN, = the AQM rarely causes burst losses, whereas overflowing an unmanaged = queue often does. With ECN, an AQM can often signal congestion = sufficiently well without dropping any packets at all. - Jonathan Morton