From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-f175.google.com (mail-wi0-f175.google.com [209.85.212.175]) (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 D27282004D7 for ; Sun, 3 Jun 2012 20:06:53 -0700 (PDT) Received: by wibhn6 with SMTP id hn6so2001522wib.10 for ; Sun, 03 Jun 2012 20:06:51 -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=kCwvnfyLw91MzqF+doidFjaGyhHzU9GmCvl06UKs+3I=; b=JeJDf0lqi/Sa7YHJS5jqVCuBJVlvnn0DAW/4s9tDH+ueWEhb1x1uykGC/V+ZXfDFg0 rA07Vn3MlRn7aG3vtgbo6CupuI68I/1BS3EhNJBWwZx3+qc9hOELyi7irQ8Wj9wwCxoP bnuurd00UCRAw/mwVyyl333ux02SYJSkYr2vwS5yauBk+uBGxdPK8tJAhha6KsO/6mcU nWZWtuEWNUm/mtVxgmyUoiUXISVZCjWI4Xncqa5hZAyM5tTtLhO/Seib2Yxd3CmYZgFG XVDqls8ThhdPD7QQ7mCwiIohOzCaqhpzhIczKG4OVq2X8t4lUhpvwNKaDJ3dAkumrWZa i+wQ== Received: by 10.216.141.98 with SMTP id f76mr9851344wej.32.1338779211465; Sun, 03 Jun 2012 20:06:51 -0700 (PDT) Received: from [192.168.239.204] (xdsl-83-150-84-172.nebulazone.fi. [83.150.84.172]) by mx.google.com with ESMTPS id et10sm17193344wib.2.2012.06.03.20.06.50 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 03 Jun 2012 20:06:50 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Jonathan Morton In-Reply-To: Date: Mon, 4 Jun 2012 06:06:48 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <970EA2AB-A3C0-4B7F-837C-F4723A1388F7@gmail.com> References: To: Haiqing Jiang X-Mailer: Apple Mail (2.1084) Cc: bloat@lists.bufferbloat.net, Eric Dumazet Subject: Re: [Bloat] Tackling bufferbloat in 3G/4G networks: A receiver-based TCP solution. 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: Mon, 04 Jun 2012 03:06:54 -0000 On 4 Jun, 2012, at 4:32 am, Haiqing Jiang wrote: > It's really excited to find the new direction to tackle bufferbloat, = on TCP layer instead of routers (like AQM). The bufferbloat problem = actually seems to be the most prominent, comparing with other networks.=20= > Therefore, we suggest the more efforts to tackling bufferbloat problem = in cellular networks and seeking a good solution in TCP layer space. I read the paper quickly, and this seems to be a good use of TCP = timestamps. It thus represents an additional way to solve (or at least = mitigate) the problem in cases where the managers of bottleneck links = are unwilling or unable to implement AQM. If you look far enough back in the list archives - search for = "Blackpool", for example - you'll see that I implemented a somewhat = cruder solution using the same basic mechanism - limiting the receive = window to prevent a single TCP stream from attempting to occupy the = entire buffer. It was cruder because it simply chose a window size = based on the bandwidth of the flow and an empirical relationship between = bandwidth and last-mile-hop latency, and didn't attempt to use = timestamps. It made a big difference for traffic from my local cell = tower to a desktop Linux machine. May I ask what happens if TCP timestamps are not available for a = particular flow, particularly one that competes with a timestamped flow? = Such crude stacks are probably getting less common now, but they = undoubtedly still exist. It would also be interesting to investigate what happens when your = scheme competes with a number of LEDBAT based flows (eg. uTP), both with = and without AQM in place. - Jonathan Morton