From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ee0-f43.google.com (mail-ee0-f43.google.com [74.125.83.43]) (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 860E5200371 for ; Sat, 4 Feb 2012 16:43:21 -0800 (PST) Received: by eekb45 with SMTP id b45so2021190eek.16 for ; Sat, 04 Feb 2012 16:43:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=cjEq/KviuVCpoyxiVRKxMAycnV+QREuWwDoIxJin2RQ=; b=FU7/KEZBDSs3ON07Kon84Qxed29ZmznKbW0IV48RWLf0ih+z+XJQufeJ+oc+m+52M1 c4/KdK0/86G3g43UUx+U43Urizc5e8eVXsmotWa+bH8K9ciXStRmV02CXkT6Qg63sikF 64uhym/k6qJb+2K5tnJWpsFe9wT/0/Bbwdxdc= Received: by 10.14.28.75 with SMTP id f51mr2198259eea.118.1328402599708; Sat, 04 Feb 2012 16:43:19 -0800 (PST) Received: from [192.168.239.42] (xdsl-83-150-84-172.nebulazone.fi. [83.150.84.172]) by mx.google.com with ESMTPS id x4sm41419881eeb.4.2012.02.04.16.43.18 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 04 Feb 2012 16:43:18 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Jonathan Morton In-Reply-To: Date: Sun, 5 Feb 2012 02:43:16 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <40C8C302-7B23-4272-8322-1D916BB0CEB2@gmail.com> References: <1325481751.2526.23.camel@edumazet-laptop> <4F046F7B.6030905@freedesktop.org> To: "George B." X-Mailer: Apple Mail (2.1084) Cc: bloat Subject: Re: [Bloat] What is fairness, anyway? was: Re: finally... winning on wired! 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, 05 Feb 2012 00:43:21 -0000 On 5 Feb, 2012, at 2:24 am, George B. wrote: > I have yet another question to ask: On a system where the vast > majority of traffic is receive traffic, what can it really do to > mitigate congestion? I send a click, I get a stream. There doesn't > seem to be a lot I can do from my side to manage congestion in the > remote server's transmit side of the link if I am an overall receiver > of traffic. >=20 > If I am sending a bunch of traffic, sure, I can do a lot with queue > management and early detection. But if I am receiving, it pretty much > just is what is and I have to play the stream that I am served. There are two good things you can do. 1) Pressure your ISP to implement managed queueing and ECN at the = head-end device, eg. DSLAM or cell-tower, and preferably at other = vulnerable points in their network too. 2) Implement TCP *receive* window management. This prevents the TCP = algorithm on the sending side from attempting to find the size of the = queues in the network. Search the list archives for "Blackpool" to see = my take on this technique in the form of a kernel patch. More = sophisticated algorithms are doubtless possible. - Jonathan Morton