From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by huchra.bufferbloat.net (Postfix) with ESMTP id 2859C21F118 for ; Tue, 23 Jul 2013 14:01:35 -0700 (PDT) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id 02F0520179; Tue, 23 Jul 2013 18:07:12 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 1C8EA63A88; Tue, 23 Jul 2013 17:00:12 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id EC22063A7C; Tue, 23 Jul 2013 17:00:12 -0400 (EDT) From: Michael Richardson To: Dave Taht In-Reply-To: References: X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Cc: aqm@ietf.org, bloat Subject: Re: [Bloat] CS244's work on netflix streaming 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: Tue, 23 Jul 2013 21:01:35 -0000 After reading both papers, I think that the take home that I got is: As we show in this paper, the problem arises because it is hard to estimate bandwidth above TCP it seems that this is a service that TCP ought to be providing, and the conclusion says so. I think that it is an API issue, not a protocol issue. If TCP knows how big the window was, it knows how much data can reasonably have been sent, and since it also knows when it grew the window, it has some notion of how long the new data took to arrive. I think that the radical solution of not trying to estimate at all, but rather, to increase the rate when the buffer is full, is rather analogous to the bufferbloat problem: vendors increased the size of buffers, and allowed them to stay full, rather than decreased them until they they were underrunning. I'm curious to know what happens if the downlink to the client is bufferbloated. It seems that the long running flow ought to accumulate significant amount of traffic with the result that the video client will see a slow cwnd growth for each chunk that it requests. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [