From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from masada.superduper.net (unknown [IPv6:2001:ba8:1f1:f263::2]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id C379921F31C for ; Sun, 31 Aug 2014 19:14:46 -0700 (PDT) Received: from 72-160-19-81.dyn.centurytel.net ([72.160.19.81] helo=[192.168.2.5]) by masada.superduper.net with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1XOH8d-0002VF-Cf; Mon, 01 Sep 2014 03:14:42 +0100 User-Agent: K-9 Mail for Android In-Reply-To: References: <91696A3A-EF44-4A1A-8070-D3AF25D0D9AC@netapp.com> <64CD1035-2E14-4CA6-8E90-C892BAD48EC6@netapp.com> <4C1661D0-32C6-48E7-BAE6-60C98D7B2D69@ifi.uio.no> <8C18A920-D0A8-4052-85EC-FF6D6039FD53@ifi.uio.no> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----QBMP3Q1HTCK1W9RNHTN06FI7WRXNEP" Content-Transfer-Encoding: 8bit From: Simon Barber Date: Sun, 31 Aug 2014 19:14:20 -0700 To: David Lang Message-ID: <63e74811-94e0-4275-b0ed-e51da78792d0@email.android.com> X-Spam-Score: -2.9 (--) Cc: bloat Subject: Re: [Bloat] sigcomm wifi 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, 01 Sep 2014 02:14:47 -0000 ------QBMP3Q1HTCK1W9RNHTN06FI7WRXNEP Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Indeed - minimum transmission time is the right metric. For wireless cards where transmission speed is determined by the host this should work very well, queue will be tightly controlled. Wireless cards that put a lot of intelligence in the card, ie packet transmission speed selection, are harder to handle well. In these cards to get good results you really need to move all the queueing code into the card, which is not going to happen. You're basically screwed and can't do a good job. Simon On August 31, 2014 5:25:05 PM PDT, David Lang wrote: >On Sun, 31 Aug 2014, Simon Barber wrote: > >> The right concept for WiFi would be TQL, time queue limit. This is >needed >> because in wifi there can be several orders of magnitude difference >in the >> speed (transmission rate) that different packets are sent at. The >purpose of >> the hardware queue is to cover for the interrupt latency, ie the time >delay >> required to keep the queue filled. Thus accounting for the time it >will take >> to transmit the packets is important. For wired interfaces with a >fixed speed >> byte counting works fine. Byte counting does not work in a wireless >> environment where the same number of bytes can take 2 or 3 different >orders of >> magnitude of time to transmit. Accounting for the expected minimum >> transmission time is critical. > >given that conditions can change while data is in the queue, I think >the right >answer is to size the queue based on the fastest possible transmission >time >(otherwise you will be running the risk of emptying the queue). Yes, it >will >lead to over buffering when the speed drops, but that would still be an > >improvement over the current situation. > >David Lang > >> Simon >> >> On August 31, 2014 3:37:07 PM PDT, David Lang wrote: >>> On Mon, 25 Aug 2014, Sebastian Moeller wrote: >>> >>>> Hi Michael, >>>> >>>> On Aug 25, 2014, at 10:01 , Michael Welzl >wrote: >>>> [...] >>>>> >>>>>> This is a case where a local proxy server can actually make a big >>> difference >>>>>> to you. The connections between your mobile devices and the local >>> proxy >>>>>> server have a short RTT and so all timeouts can be nice and >short, >>> and then >>>>>> the proxy deals with the long RTT connections out to the >Internet. >>>>> >>>>> Adding a proxy to these considerations only complicates them: it's >a >>> hard >>>>> enough trade-off when we just ask ourselves: how large should a >>> buffer for >>>>> the sake of link layer retransmissions be? (which is closely >>> related to the >>>>> question: how often should a link layer try to retransmit before >>> giving up?) >>>>> That's what my emails were about. I suspect that we don't have a >>> good answer >>>>> to even these questions, and I suspect that we'd better off having >>> something >>>>> dynamic than fixed default values. >>>> >>>> What about framing the retransmissions not in number but rather in >>> time? >>>> For example the maximum of either time to transmit a few (say 3?) >>> packet at >>>> the current data rate (or maybe one rate lower than current to >allow >>>> setoriating signal quality) or 20ms (pulled out of thin air, would >>> need some >>>> research). The first should make sure we actually retransmit to >>> overcome >>>> glitches, and the second should make sure that RTT does not >increase >>> to >>>> dramatically. This basically assumes that for reasonable >interactive >>> traffic >>>> we only have a given RTT budget and should make sure not to >overspend >>> ;) >>> >>> Yep, just like BQL helped a lot on the wired side, because it's a >good >>> stand-in >>> for the time involved, we need to get the same concept through the >wifi >>> stack >>> and drivers. >>> >>> David Lang >>> _______________________________________________ >>> Bloat mailing list >>> Bloat@lists.bufferbloat.net >>> https://lists.bufferbloat.net/listinfo/bloat >> >> -- Sent from my Android device with K-9 Mail. Please excuse my brevity. ------QBMP3Q1HTCK1W9RNHTN06FI7WRXNEP Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Indeed - minimum transmission time is the right metric. For wireless cards where transmission speed is determined by the host this should work very well, queue will be tightly controlled. Wireless cards that put a lot of intelligence in the card, ie packet transmission speed selection, are harder to handle well. In these cards to get good results you really need to move all the queueing code into the card, which is not going to happen. You're basically screwed and can't do a good job.

Simon

On August 31, 2014 5:25:05 PM PDT, David Lang <david@lang.hm> wrote:
On Sun, 31 Aug 2014, Simon Barber wrote:

 The right concept for WiFi would be TQL, time queue limit. This is needed 
 because in wifi there can be several orders of magnitude difference in the 
 speed (transmission rate) that different packets are sent at. The purpose of 
 the hardware queue is to cover for the interrupt latency, ie the time delay 
 required to keep the queue filled. Thus accounting for the time it will take 
 to transmit the packets is important. For wired interfaces with a fixed speed 
 byte counting works fine. Byte counting does not work in a wireless 
 environment where the same number of bytes can take 2 or 3 different orders of 
 magnitude of time to transmit. Accounting for the expected minimum 
 transmission time is critical.

given that
conditions can change while data is in the queue, I think the right 
answer is to size the queue based on the fastest possible transmission time 
(otherwise you will be running the risk of emptying the queue). Yes, it will 
lead to over buffering when the speed drops, but that would still be an 
improvement over the current situation.

David Lang

 Simon

 On August 31, 2014 3:37:07 PM PDT, David Lang <david@lang.hm> wrote:
 On Mon, 25 Aug 2014, Sebastian Moeller wrote:

 Hi Michael,

 On Aug 25, 2014, at 10:01 , Michael Welzl <michawe@ifi.uio.no>
wrote:
 [...]

 This is a case where a local proxy server can actually make a big
 difference
 to you. The connections between your mobile devices and the local
 proxy
 server have a short RTT and so all timeouts can be nice and short,
 and then
 the proxy deals with the long RTT connections out to the Internet.

 Adding a proxy to these considerations only complicates them: it's a
 hard
 enough trade-off when we just ask ourselves: how large should a
 buffer for
 the sake of link layer retransmissions be?  (which is closely
 related to the
 question: how often should a link layer try to retransmit before
 giving up?)
 That's what my emails were about. I suspect that we don't have a
 good answer
 to even these questions, and I suspect that we'd better off having
 something
 dynamic than fixed default values.

  What
about framing the retransmissions not in number but rather in
 time?
 For example the maximum of either time to transmit a few (say 3?)
 packet at
 the current data rate (or maybe one rate lower than current to allow
 setoriating signal quality) or 20ms (pulled out of thin air, would
 need some
 research). The first should make sure we actually retransmit to
 overcome
 glitches, and the second should make sure that RTT does
not increase
 to
 dramatically. This basically assumes that for reasonable interactive
 traffic
 we only have a given RTT budget and should make sure not to overspend
 ;)

 Yep, just like BQL helped a lot on the wired side, because it's a good
 stand-in
 for the time involved, we need to get the same concept through the wifi
 stack
 and drivers.

 David Lang

 Bloat mailing list
 Bloat@lists.bufferbloat.net
 https://lists.bufferbloat.net/listinfo/bloat


--
Sent from my Android device with K-9 Mail. Please excuse my brevity. ------QBMP3Q1HTCK1W9RNHTN06FI7WRXNEP--