[OpenWrt-Devel] ath9k: fix dynack in IBSS mode

[Lorenzo Bianconi]

> On Mon, Mar 4, 2019 at 10:31 AM Lorenzo Bianconi
> <lorenzo.bianconi at redhat.com> wrote:
> >
> > > On Mon, Mar 4, 2019 at 1:07 AM Lorenzo Bianconi
> > > <lorenzo.bianconi at redhat.com> wrote:
> > > >
> > > > > Lorenzo,    I've pulled out all patches related to extended ham radio
> > > > > channels and ath9k is same out of openwrt 18.06.2.    I replaced wpad-mini
> > > > > with the full version and "option encryption  psk2".   In testing between a
> > > > > mickrotik QRT5 and LHG5 about 10m apart (roof to office),  ack_to will
> > > > > float up to ~200, then settle down to ~55 -- seems about right.   However,
> > > > > I do not see any late ack messages in the debug logging.     Shouldn't I be
> > > > > seeing late acks?   I can send full debug data on both sides of the fence.
> > > > >  Is there anything that doesn't sound right in my setup?  I wanted to do
> > > > > one more clean test to capture logs.
> > > >
> > > > Hi Joe,
> > > >
> > > > this is the expected behavior since 'late acks' are triggered just when the real
> > > > ack-timeout is higher than the initial default value (64us IIRC). In other
> > > > words 'late acks' are necessary just on pretty long links
> > > >
> > > > Regards,
> > > > Lorenzo
> > > >
> >
> > Hi Joe,
> >
> > please keep the ml in cc
> >
> > >
> > > Intuitively, aren't 'late acks' expected regardless of the distance?
> > >  Is there yet another data point for the algorithm to oscillate in to
> > > an optimal ack_to setting?  For a mobile use case, with increasing
> > > distance apart, there'd need to be a 'late ack' equivalent to trigger
> > > increasing values?   I'm fundamentally trying to understand if any
> > > there are any limitations to be aware of when applying dynack -
> > > mobile/fixed short/long distances,  P2P/MP2P/P2MP/MP2MP.
> >
> > 'late ack' means that we received an ack for a packet where ack-timeout is already
> > expired since the configured timeout was too low for the real distance.
> > If the real ack-timeout is less than the configured initial value (64us --> ~ 10Km),
> > it is expected to not detected any 'late acks'. In this scenario the ack timeout
> > should just converge to a good value.
> > If the real distance is grater than 10km we have to dump the ack-timeout in order
> > to grab the station and estimate the real timeout (we need to dump the
> > ack-timeout since the estimation is done through data-ack transmissions).
> > Are we on the same page?
> >
> > Regards,
> > Lorenzo
> >
> 
> Thanks for taking the time to get to this detail.
> 
> Still a little fuzzy on what packets are in scope.   When not late ack
> state:  xmit a 'packet' and expect an ack in return  -- all data
> 'packets' regardless if using wpa_supplicant or not?  estimate and
> update ack_to
> 
> "in order to grab the station and estimate the real timeout"
> Context is in a late ack state, all the acks are late "done through
> data-ack transmissions".   Thus what does it mean to "grab the station
> and estimate" -- is this the dependency to wpa_supplicant and turning
> to measuring the handshaking packets generated by wpa_supplicant?
> And if I understand correctly, this state can only occur if the intial
> ack_to is shorter than physical distance.  If initial ack_to is
> greater than physical, then we never get into this state.

the main idea behind dynack is to measure the delta time between packet
transmission and the corresponding ack reception (~ 2 * acktimeout).
To do so we need to correlate the ack with the relative data packet.
This is easy if the already configured acktimeout is higher than the
station distance since the related ack will arrive before the timeout
expiration time.
If the station distance is higher than the current acktimeout we need to know
that a new station is connecting to the network since we need to dump the
acktimeout in order to start estimating its distance. This is done through
association/authentication packets and AFAIK they are not sent in IBSS mode if
we do not run wpa_supplicant.

Regards,
Lorenzo

> 
> Initial value is
> /* ackto = slottime + sifs + air delay */
>  u32 ackto = 9 + 16 + 64;
> 
> In comparison, I see a static distance to ack_to relationship as:
> 
> ack_to = (distance in meters) / 151.51515151 + 64
> 
> A static setting is never below 64, but with dynack, I've observed
> down to 55 at 10m real distance.   I assume this isn't significant to
> be concerned about.
> 
> Joe
> 
> > >
> > > BTW, here's a ~77km long distance link that recently came online in
> > > Alaska in 3GHz:
> > > https://www.arednmesh.org/content/site-summit-yetna-link    These
> > > devices are  5GHz motherboards with -2GHz down-converters.
> > >
> > > Joe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20190305/89cc34bd/attachment.sig>
-------------- next part --------------
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel