From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp78.iad3a.emailsrvr.com (smtp78.iad3a.emailsrvr.com [173.203.187.78]) (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 55E6021FE72 for ; Fri, 7 Aug 2015 14:46:39 -0700 (PDT) Received: from smtp10.relay.iad3a.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp10.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 5B5A5280762; Fri, 7 Aug 2015 17:46:38 -0400 (EDT) Received: from app39.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp10.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 3C9BD28075D; Fri, 7 Aug 2015 17:46:38 -0400 (EDT) X-Sender-Id: dpreed@reed.com Received: from app39.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by 0.0.0.0:25 (trex/5.4.2); Fri, 07 Aug 2015 21:46:38 GMT Received: from reed.com (localhost.localdomain [127.0.0.1]) by app39.wa-webapps.iad3a (Postfix) with ESMTP id 2910D380044; Fri, 7 Aug 2015 17:46:38 -0400 (EDT) Received: by apps.rackspace.com (Authenticated sender: dpreed@reed.com, from: dpreed@reed.com) with HTTP; Fri, 7 Aug 2015 17:46:38 -0400 (EDT) Date: Fri, 7 Aug 2015 17:46:38 -0400 (EDT) From: dpreed@reed.com To: "David Lang" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_20150807174638000000_27755" 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> <6E08E48D-5D53-48E5-B088-2D1DB5E566AD@gmail.com> X-Auth-ID: dpreed@reed.com Message-ID: <1438983998.16576420@apps.rackspace.com> X-Mailer: webmail/11.5.5-RC X-Mailman-Approved-At: Sat, 08 Aug 2015 08:27:43 -0700 Cc: cerowrt-devel@lists.bufferbloat.net, make-wifi-fast@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: Fri, 07 Aug 2015 21:47:08 -0000 ------=_20150807174638000000_27755 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0A =0AOn Friday, August 7, 2015 4:03pm, "David Lang" said:= =0A> =0A=0A> Wifi is the only place I know of where the transmit bit rate i= s going to vary=0A> depending on the next hop address.=0A=0A=0AThis is an i= nteresting core issue. The question is whether additional queueing helps o= r hurts this, and whether the MAC protocol of WiFi deals well or poorly wit= h this issue. It is clear that this is a peculiarly WiFi'ish issue.=0A =0A= It's not clear that the best transmit rate remains stable for very long, or= even how to predict the "best rate" for the next station since the next st= ation is one you may not have transmitted to for a long time, so your "best= rate" information is old. Queueing makes information about the channel ol= der, by binding it too early. Sending longer frames means retransmitting l= onger frames when they don't get through, rather than agilely picking a bet= ter rate after a few bits.=0A =0AThe MAC protocol really should give the re= ceiver some opportunity to control the rate of the next packet it gets (whi= ch it can do because it can measure the channel from the transmitter to its= elf, by listening to prior transmissions). Or at least to signal channel c= hanges that might require a new signalling rate.=0A =0AThis suggests that a= transmitter might want to "warn" a receiver that some packets will be comi= ng its way, so the receiver can preemptively change the desired rate. Thus= , perhaps an RTS-CTS like mechanism can be embedded in the MAC protocol, wh= ich requires that the device "look ahead" at the packets it might be sendin= g.=0A =0AOn the other hand, that only works if the transmitter deliberately= congests itself so that it has a queue built up to look at.=0A =0AThe trad= eoffs are not obvious here at all. On the other hand, one could do somethi= ng much simpler - just have the transmitter slow down to the worst-case rat= e required by any receiving system.=0A =0AAs the number of stations in rang= e gets larger, though, it seems unlikely that "batching" multiple packets t= o the same destination is a good idea at all - because to achieve that, one= must have n_destinations * batch_size chunks of data queued in the system = as a whole, and that gets quite large. I suspect it would be better to fin= d a lower level way to just keep the packets going out as fast as they arri= ve, so no clog occurs, and to slow down the stuff at the source as quickly = as possible.=0A =0A[one should also dive into the reason for maintaining va= riable rates - multipath to a particular destination may require longer sym= bols for decoding without ISI. And when multipath is involved, you may hav= e to retransmit at a slower rate. There's usually not much "noise" at the r= eceiver compared to the multipath environment. (one of the reasons why mesh= can be a lot better is that shorter distances have much less multipath eff= ect, so you can get higher symbol rates by going multi-hop, and of course h= igher symbol rates compensate for more airtime occupied by a packet due to = repeating).]=0A =0A ------=_20150807174638000000_27755 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

&nbs= p;

=0A

On Friday, August 7, 2015 4:03pm, "Da= vid Lang" <david@lang.hm> said:
> 

=0A
=0A

> Wifi is the only pla= ce I know of where the transmit bit rate is going to vary
> dependi= ng on the next hop address.

=0A

= This is an interesting core issue.  The question is whether additional= queueing helps or hurts this, and whether the MAC protocol of WiFi deals w= ell or poorly with this issue.  It is clear that this is a peculiarly = WiFi'ish issue.

=0A

 

=0A

It's not clear that the best transmit rate remains stable= for very long, or even how to predict the "best rate" for the next station= since the next station is one you may not have transmitted to for a long t= ime, so your "best rate" information is old.  Queueing makes informati= on about the channel older, by binding it too early.  Sending longer f= rames means retransmitting longer frames when they don't get through, rathe= r than agilely picking a better rate after a few bits.

=0A

 

=0A

The MAC protocol r= eally should give the receiver some opportunity to control the rate of the = next packet it gets (which it can do because it can measure the channel fro= m the transmitter to itself, by listening to prior transmissions).  Or= at least to signal channel changes that might require a new signalling rat= e.

=0A

 

=0A

This suggests that a transmitter might want to "warn" a receiver that = some packets will be coming its way, so the receiver can preemptively chang= e the desired rate.  Thus, perhaps an RTS-CTS like mechanism can be em= bedded in the MAC protocol, which requires that the device "look ahead" at = the packets it might be sending.

=0A

 <= /p>=0A

On the other hand, that only works if th= e transmitter deliberately congests itself so that it has a queue built up = to look at.

=0A

 

=0A

The tradeoffs are not obvious here at all.  On the other= hand, one could do something much simpler - just have the transmitter slow= down to the worst-case rate required by any receiving system.

=0A

 

=0A

As the num= ber of stations in range gets larger, though, it seems unlikely that "batch= ing" multiple packets to the same destination is a good idea at all - becau= se to achieve that, one must have n_destinations * batch_size chunks of dat= a queued in the system as a whole, and that gets quite large.  I suspe= ct it would be better to find a lower level way to just keep the packets go= ing out as fast as they arrive, so no clog occurs, and to slow down th= e stuff at the source as quickly as possible.

=0A

 

=0A

[one should also dive = into the reason for maintaining variable rates - multipath to a partic= ular destination may require longer symbols for decoding without ISI.  = ;And when multipath is involved, you may have to retransmit at a slower rat= e. There's usually not much "noise" at the receiver compared to the multipa= th environment. (one of the reasons why mesh can be a lot better is that sh= orter distances have much less multipath effect, so you can get higher symb= ol rates by going multi-hop, and of course higher symbol rates compensate f= or more airtime occupied by a packet due to repeating).]

=0A

 

=0A

 

=0A ------=_20150807174638000000_27755--