From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-we0-f171.google.com (mail-we0-f171.google.com [74.125.82.171]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id C7849200B33 for ; Sat, 7 Apr 2012 12:08:50 -0700 (PDT) Received: by werm1 with SMTP id m1so3691523wer.16 for ; Sat, 07 Apr 2012 12:08:49 -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:x-mailer; bh=y7y4ljJXKe0Kfv9LkE68qPLGdAJwEPJWaRf0kmbQnwI=; b=aY8TMP1EZ+C6akr441PYdLc+hwH7eRc2cerS5uCBxiRZEh58DqUDjSJUd4bd+ddaTE fMXPSLlyIB87klGE6WPvzpgU3jtr19gehr6w5V9MtNFiCgorxES5O0fYxLKywC+cXI1o IttElryu3d827rgWvxFTyxEvxYKwr3pbNhIX4IT9wbSIy9thp41f9wXST/IO51cH+Iiu OLgDmYkpkfCNBmtelW3Im7j287J3eRFEUAhiI5zIKafn8ErfL8jYpKqqPyJpdCRY+3Ps /jfSiddnlIxbE764WtPx3ksNOJbe5hK6Yn+C/GyTuKeLZN5DW785akeH/PZtEMc1u3m5 2Uow== Received: by 10.216.53.200 with SMTP id g50mr1232079wec.2.1333825729051; Sat, 07 Apr 2012 12:08:49 -0700 (PDT) Received: from [192.168.1.14] (xdsl-83-150-84-172.nebulazone.fi. [83.150.84.172]) by mx.google.com with ESMTPS id n8sm26971248wix.10.2012.04.07.12.08.47 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 07 Apr 2012 12:08:48 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Jonathan Morton In-Reply-To: <20120407190134.GF21452@uio.no> Date: Sat, 7 Apr 2012 22:08:46 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <9C293399-0554-4CE3-8282-22FCF4B545BF@gmail.com> References: <20120406213725.GA12641@uio.no> <20120406222138.GB12641@uio.no> <1333811327.30705.4.camel@edumazet-laptop> <20120407153548.GC21452@uio.no> <20120407181034.GD21452@uio.no> <20120407185456.GE21452@uio.no> <20120407190134.GF21452@uio.no> To: "Steinar H. Gunderson" X-Mailer: Apple Mail (2.1084) Cc: bloat@lists.bufferbloat.net Subject: Re: [Bloat] Best practices for paced TCP on Linux? 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, 07 Apr 2012 19:08:51 -0000 On 7 Apr, 2012, at 10:01 pm, Steinar H. Gunderson wrote: > I got reports from people in Norway that this instantly stopped the = problems > on the HD stream, so incredibly enough, it may have worked. >=20 > I don't understand these mechanisms. Why would a smaller send window = help? > Less burstiness? That's the short answer, yes. It limits the amount of data that can be = "in the network" at any one time, which is where it needs to find = buffers whenever the link speed narrows. If it needs to find buffers = but they aren't big enough to hold all the data, packets are lost. Another side effect is that it increases the "resonant frequency" of the = connection, so the receiver can communicate about lost packets and = actually receive the retransmissions before it's own buffer runs out. Note also that once the client buffer is satisfied, it only needs to get = data smoothly, almost one frame at a time, whereas if it has just had to = deal with a major loss event, the buffer will be empty and needs a lot = of data to fill it. This latter effect is why, once the problem has = occurred, it keeps on occurring. The periodicity probably is = synchronised - to the video keyframes! - Jonathan