From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp102.iad3a.emailsrvr.com (smtp102.iad3a.emailsrvr.com [173.203.187.102]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id 805CB21FBC2 for ; Mon, 3 Aug 2015 08:44:32 -0700 (PDT) Received: from smtp13.relay.iad3a.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp13.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id E5CBE100FFF; Mon, 3 Aug 2015 11:44:30 -0400 (EDT) Received: from app43.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp13.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id C1C7D100EC6; Mon, 3 Aug 2015 11:44:30 -0400 (EDT) X-Sender-Id: dpreed@reed.com Received: from app43.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by 0.0.0.0:25 (trex/5.4.2); Mon, 03 Aug 2015 15:44:30 GMT Received: from reed.com (localhost.localdomain [127.0.0.1]) by app43.wa-webapps.iad3a (Postfix) with ESMTP id ADEA9380048; Mon, 3 Aug 2015 11:44:30 -0400 (EDT) Received: by apps.rackspace.com (Authenticated sender: dpreed@reed.com, from: dpreed@reed.com) with HTTP; Mon, 3 Aug 2015 11:44:30 -0400 (EDT) Date: Mon, 3 Aug 2015 11:44:30 -0400 (EDT) From: dpreed@reed.com To: "Jonathan Morton" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_20150803114430000000_20728" Importance: Normal X-Priority: 3 (Normal) X-Type: html In-Reply-To: References: <356F5FEE-9FBD-4FF9-AC17-86A642D918A4@gmail.com> <5CC1DC90-DFAF-4A4D-8204-16CD4E20D6E3@gmx.de> <4D24A497-5784-493D-B409-F704804326A7@gmx.de> <1438361254.45977158@apps.rackspace.com> X-Auth-ID: dpreed@reed.com Message-ID: <1438616670.710822730@apps.rackspace.com> X-Mailer: webmail/11.5.5-RC X-Mailman-Approved-At: Sat, 08 Aug 2015 08:27:43 -0700 Cc: make-wifi-fast@lists.bufferbloat.net, cerowrt-devel@lists.bufferbloat.net Subject: Re: [Make-wifi-fast] [Cerowrt-devel] [tsvwg] Comments on draft-szigeti-tsvwg-ieee-802-11e X-BeenThere: make-wifi-fast@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2015 15:45:01 -0000 ------=_20150803114430000000_20728 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0AIt's not infeasible to make queues shorter. In any case, the throughput= of a link does not increase above the point where there is always one pack= et ready to go by the time the currently outgoing packet is completed. It = physically cannot do better than that.=0A=0AIf hardware designers can't cre= ate an interface that achieves that bound I'd be suspicious that they under= stand how to design hardware. In the case of WiFi, this also includes the = MAC protocol being designed so that when the current packet on the air term= inates, the next packet can be immediately begun - that's a little more sub= tle.=0A=0ABut my point here is that one needs to look at the efficiency of = the system as a whole (in context), and paradoxically to the hardware desig= ner mindset, the proper way to think about that efficiency is NOT about lin= k throughput maximization - instead it is an end-to-end property. One has = very little to do with the other. Queueing doesn't affect link throughput = beyond the "double buffering" effect noted above: at most one packet queued= behind the currently transmitting packet.=0A =0ARegarding TXOP overhead - = rather than complicated queueing, just allow packets to be placed in line *= while the currently transmitting packet is going out*, and changed up to th= e point in time when they begin transmitting. This is trivial in hardware.= =0A=0A=0AOn Friday, July 31, 2015 1:04pm, "Jonathan Morton" said:=0A=0A=0A=0A> I think that is achievable, *even if there is a= WiFi network in the middle*, by thinking about the fact that the shared ai= rwaves in a WiFi network behaves like a single link, so all the queues on i= ndividual stations are really *one queue*, and that the optimal behavior of= that link will be achieved if there is at most one packet queued at a time= .=0AI agree that queues should be kept short in general. However I don't th= ink single packet queues are achievable in the general case.=0AThe general = case includes Wi-Fi networks, whose TXOP overhead is so ruinously heavy tha= t sending single MTU sized packets is inefficient. Aggregating multiple pac= kets into one TXOP requires those several packets to be present in the buff= er at that moment.=0AThe general case includes links which vary in throughp= ut frequently, perhaps on shorter timescales than an RTT, so either packets= must be buffered or capacity is left unused. This also happens to include = Wi-Fi, but could easily include a standard wired link whose competing load = varies.=0AThe endpoints do not have and do not receive sufficient informati= on in sufficient time to reliably make packets arrive at nodes just in time= to be transmitted. Not even with ECN, not even with the wet dreams of the = DCTCP folks, and not even with ELR (though ELR should be able to make it ha= ppen under steady conditions, there are still transient conditions in the g= eneral case).=0A- Jonathan Morton ------=_20150803114430000000_20728 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

It's= not infeasible to make queues shorter.  In any case, the throughput o= f a link does not increase above the point where there is always one packet=  ready to go by the time the currently outgoing packet is completed. &= nbsp;It physically cannot do better than that.

If hardware desig= ners can't create an interface that achieves that bound I'd be suspicious t= hat they understand how to design hardware.  In the case of WiFi, this= also includes the MAC protocol being designed so that when the current pac= ket on the air terminates, the next packet can be immediately begun - that'= s a little more subtle.

But my point here is that one needs to l= ook at the efficiency of the system as a whole (in context), and paradoxica= lly to the hardware designer mindset, the proper way to think about that ef= ficiency is NOT about link throughput maximization - instead it is an end-t= o-end property.  One has very little to do with the other.  Queue= ing doesn't affect link throughput beyond the "double buffering" effect not= ed above: at most one packet queued behind the currently transmitting packe= t.

=0A

 

=0A

Regarding TXOP overhead - rather than complicated queueing, just allow= packets to be placed in line *while the currently transmitting packet is g= oing out*, and changed up to the point in time when they begin transmitting= . This is trivial in hardware.

=0A=0A



On Fr= iday, July 31, 2015 1:04pm, "Jonathan Morton" <chromatix99@gmail.com>= said:

=0A
=0A

> I think that is achievable, *even if there = is a WiFi network in the middle*, by thinking about the fact that the share= d airwaves in a WiFi network behaves like a single link, so all the queues = on individual stations are really *one queue*, and that the optimal behavio= r of that link will be achieved if there is at most one packet queued at a = time.

=0A

I agree that queues sh= ould be kept short in general. However I don't think single packet queues a= re achievable in the general case.

=0A

The general case includes Wi-Fi networks, whose TXOP overhead is s= o ruinously heavy that sending single MTU sized packets is inefficient. Agg= regating multiple packets into one TXOP requires those several packets to b= e present in the buffer at that moment.

=0A

The general case includes links which vary in throughput freque= ntly, perhaps on shorter timescales than an RTT, so either packets must be = buffered or capacity is left unused. This also happens to include Wi-Fi, bu= t could easily include a standard wired link whose competing load varies.=0A

The endpoints do not have and= do not receive sufficient information in sufficient time to reliably make = packets arrive at nodes just in time to be transmitted. Not even with ECN, = not even with the wet dreams of the DCTCP folks, and not even with ELR (tho= ugh ELR should be able to make it happen under steady conditions, there are= still transient conditions in the general case).

=0A

- Jonathan Morton

=0A
 ------=_20150803114430000000_20728--