[RFC] API for setting ACK timeout

[RFC] API for setting ACK timeout

[Lukáš Turek]

Hi,

we discussed this in ath5k-devel, but it involves a mac80211 extension, so I'm 
bringing it here.

Although Wi-Fi was designed for outdoor use, it's also sometimes used for long 
distance outdoor links. However, long distance links require longer ACK 
timeout, as packets travel "only" at the speed of light and every kilometer 
adds almost 7 microseconds to the roundtrip. So for a driver to be usable 
outdoors it has to permit setting ACK timeout from userspace.

Currently this is supported only by out-of-tree Madwifi driver for Atheros 
hardware. However, modification of ACK timeout is not an Atheros specific 
feature. According to a quick skim over the source code in 
drivers/net/wireless, besides ath5k and ath9k it's at least supported by 
rt2x00, rtl818x and maybe zd1211.

I think the current hardware support is sufficient for a generic mac80211 
solution. The exact interpretation of ACK timeout value is hardware specific, 
so I propose a higher level API operating with link distance.

It consists of a new nl80211 parameter:
[NL80211_ATTR_WIPHY_DISTANCE] = { .type = NLA_U32 },

The value of the parameter would be a link distance in meters, so after the 
support is added to iw one could set the ACK timeout on a 3km link using:
# iw phy0 set distance 3000

Another required change would be extending cfg80211_ops by functions 
set_distance and get_distance. Calculation of appropriate ACK timeout (and in 
the case of ath5k, also CTS timeout and slottime) for the distance would be 
left to the driver (it's a trivial formula).

I can prepare the patches, if you think these extension would be acceptable. 
Suggestions are welcome.

Lukas Turek

Re: [RFC] API for setting ACK timeout

[Gábor Stefanik]

On Thu, Nov 26, 2009 at 6:26 PM, Lukáš Turek <8an@praha12.net> wrote:
> Hi,
>
> we discussed this in ath5k-devel, but it involves a mac80211 extension, so I'm
> bringing it here.
>
> Although Wi-Fi was designed for outdoor use, it's also sometimes used for long
> distance outdoor links. However, long distance links require longer ACK
> timeout, as packets travel "only" at the speed of light and every kilometer
> adds almost 7 microseconds to the roundtrip. So for a driver to be usable
> outdoors it has to permit setting ACK timeout from userspace.
>
> Currently this is supported only by out-of-tree Madwifi driver for Atheros
> hardware. However, modification of ACK timeout is not an Atheros specific
> feature. According to a quick skim over the source code in
> drivers/net/wireless, besides ath5k and ath9k it's at least supported by
> rt2x00, rtl818x and maybe zd1211.
>
> I think the current hardware support is sufficient for a generic mac80211
> solution. The exact interpretation of ACK timeout value is hardware specific,
> so I propose a higher level API operating with link distance.
>
> It consists of a new nl80211 parameter:
> [NL80211_ATTR_WIPHY_DISTANCE] = { .type = NLA_U32 },

Why not instead allow setting ACK timeout directly, e.g. in
milliseconds? (Similar to how signal strength is almost always
returned in dBm, even though the devices themselves use all kinds of
units.)

>
> The value of the parameter would be a link distance in meters, so after the
> support is added to iw one could set the ACK timeout on a 3km link using:
> # iw phy0 set distance 3000
>
> Another required change would be extending cfg80211_ops by functions
> set_distance and get_distance. Calculation of appropriate ACK timeout (and in
> the case of ath5k, also CTS timeout and slottime) for the distance would be
> left to the driver (it's a trivial formula).
>
> I can prepare the patches, if you think these extension would be acceptable.
> Suggestions are welcome.
>
> Lukas Turek
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>



-- 
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)

Re: [RFC] API for setting ACK timeout

[Lukáš Turek]

[-- Attachment #1: Type: text/plain, Size: 724 bytes --]

On 26.11.2009 18:32 Gábor Stefanik wrote:
> Why not instead allow setting ACK timeout directly, e.g. in
> milliseconds? (Similar to how signal strength is almost always
> returned in dBm, even though the devices themselves use all kinds of
> units.)

Because the timeout does not depend on the distance only, the calculation 
involves at least the transmit duration of an ACK frame, and sometimes more, 
depending on the hardware (in one of them I saw they added DIFS to the 
timeout, forgot which one).

And on Atheros hardware there are three values that depend on link distance: 
ACK timeout, CTS timeout and slot time.

So the equivalent of dBm here is the link distance, not ACK timeout.

Lukas Turek

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [RFC] API for setting ACK timeout

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 1094 bytes --]

On Thu, 2009-11-26 at 18:26 +0100, Lukáš Turek wrote:

> It consists of a new nl80211 parameter:
> [NL80211_ATTR_WIPHY_DISTANCE] = { .type = NLA_U32 },
> 
> The value of the parameter would be a link distance in meters, so after the 
> support is added to iw one could set the ACK timeout on a 3km link using:
> # iw phy0 set distance 3000
> 
> Another required change would be extending cfg80211_ops by functions 
> set_distance and get_distance. Calculation of appropriate ACK timeout (and in 
> the case of ath5k, also CTS timeout and slottime) for the distance would be 
> left to the driver (it's a trivial formula).
> 
> I can prepare the patches, if you think these extension would be acceptable. 
> Suggestions are welcome.

I discussed this with Alina a while back (in private, she didn't want to
discuss in English) and we came to the conclusion that set_coverage()
should be done like 802.11-2007 17.3.8.6 specifies for 5ghz, but could
be done for 2.4ghz as well. Thoughts? It would also allow us to actually
advertise that to compatible clients.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [RFC] API for setting ACK timeout

[Lukáš Turek]

[-- Attachment #1: Type: text/plain, Size: 1267 bytes --]

On 26.11.2009 19:18 Johannes Berg wrote:
> I discussed this with Alina a while back (in private, she didn't want to
> discuss in English) and we came to the conclusion that set_coverage()
> should be done like 802.11-2007 17.3.8.6 specifies for 5ghz, but could
> be done for 2.4ghz as well. Thoughts? It would also allow us to actually
> advertise that to compatible clients.

If I understand the standard correctly, it means the slottime should be
(9 + propagation_delay), which equals (9 + distance / 300). And that's 
basically the same as the formula from Madwifi's athctrl I wanted to use:
int slottime = 9 + (distance / 300) + ((distance % 300) ? 1 : 0);

The main difference is that the coverage classes have an upper limit under 
28km, but I don't see the point in artifically limiting maximum link distance 
(30km link could be done with big enough antennas).

And I would prefer if the userspace API operated with distance rather than 
coverage classes, because it allows the user to set it correctly without 
reading a thousand page document. The coverage class could be then calculated 
for use in beacons as you proposed. Of course, in this case we would be 
constrained by the maximum coverage class in the standard.

Lukas Turek

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [RFC] API for setting ACK timeout

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 1636 bytes --]

On Thu, 2009-11-26 at 20:14 +0100, Lukáš Turek wrote:
> On 26.11.2009 19:18 Johannes Berg wrote:
> > I discussed this with Alina a while back (in private, she didn't want to
> > discuss in English) and we came to the conclusion that set_coverage()
> > should be done like 802.11-2007 17.3.8.6 specifies for 5ghz, but could
> > be done for 2.4ghz as well. Thoughts? It would also allow us to actually
> > advertise that to compatible clients.

My standard reference was obviously crap -- let's see, 7.3.2.9 is
better.

> If I understand the standard correctly, it means the slottime should be
> (9 + propagation_delay), which equals (9 + distance / 300). And that's 
> basically the same as the formula from Madwifi's athctrl I wanted to use:
> int slottime = 9 + (distance / 300) + ((distance % 300) ? 1 : 0);

That formula is a weird way of rounding up ...

> The main difference is that the coverage classes have an upper limit under 
> 28km, but I don't see the point in artifically limiting maximum link distance 
> (30km link could be done with big enough antennas).
> 
> And I would prefer if the userspace API operated with distance rather than 
> coverage classes, because it allows the user to set it correctly without 
> reading a thousand page document. The coverage class could be then calculated 
> for use in beacons as you proposed. Of course, in this case we would be 
> constrained by the maximum coverage class in the standard.

No, you want the _user_ API to be operated with distance, not the
_userspace_ API. Conversion like that ought to be done in iw, not the
kernel.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [RFC] API for setting ACK timeout

[Lukáš Turek]

[-- Attachment #1: Type: text/plain, Size: 641 bytes --]

On 26.11.2009 20:25 Johannes Berg wrote:
> My standard reference was obviously crap -- let's see, 7.3.2.9 is
> better.
Yes, I found the table. And now I also noticed the real difference: the slot 
time according to the standard rises in a step of three (which means ACK 
timeout will rise in a step of six). It's quite significant loss of 
precision, but it probably shouldn't make much difference in throughput.

Anyway, this solutions would be good enough for us if it was accepted. So you 
propose to add parameter NL80211_ATTR_WIPHY_COVERAGE to nl80211 and functions 
set_coverage/get_coverage to cfg80211_ops?

Lukas Turek

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [RFC] API for setting ACK timeout

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 900 bytes --]

On Thu, 2009-11-26 at 21:13 +0100, Lukáš Turek wrote:
> On 26.11.2009 20:25 Johannes Berg wrote:
> > My standard reference was obviously crap -- let's see, 7.3.2.9 is
> > better.
> Yes, I found the table. And now I also noticed the real difference: the slot 
> time according to the standard rises in a step of three (which means ACK 
> timeout will rise in a step of six). It's quite significant loss of 
> precision, but it probably shouldn't make much difference in throughput.

It only affects lost packets anyway, no?

> Anyway, this solutions would be good enough for us if it was accepted. So you 
> propose to add parameter NL80211_ATTR_WIPHY_COVERAGE to nl80211 and functions 
> set_coverage/get_coverage to cfg80211_ops?

Would that be sufficient? It'd be kinda cool if mac80211 auto-configured
itself if it picked up a beacon that had this information, etc.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [RFC] API for setting ACK timeout

[Lukáš Turek]

[-- Attachment #1: Type: text/plain, Size: 601 bytes --]

On 26.11.2009 21:15 Johannes Berg wrote:
> It only affects lost packets anyway, no?
Yes, it does, and 6us is still nothing compared to the transmit duration
(at least 100us).

> Would that be sufficient? It'd be kinda cool if mac80211 auto-configured
> itself if it picked up a beacon that had this information, etc.
We just need an API for setting ACK timeout on long distance point-to-point 
links, so this is definitely enough. Unfortunately I can't promise I will 
have enough time to implement the automatic configuration, although I see it 
would be useful for us too.

Lukas Turek

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [RFC] API for setting ACK timeout

[Benoit PAPILLAULT]

Lukáš Turek a écrit :
> Hi,
> 
> we discussed this in ath5k-devel, but it involves a mac80211 extension, so I'm 
> bringing it here.
> 
> Although Wi-Fi was designed for outdoor use, it's also sometimes used for long 
> distance outdoor links. However, long distance links require longer ACK 
> timeout, as packets travel "only" at the speed of light and every kilometer 
> adds almost 7 microseconds to the roundtrip. So for a driver to be usable 
> outdoors it has to permit setting ACK timeout from userspace.
> 
> Currently this is supported only by out-of-tree Madwifi driver for Atheros 
> hardware. However, modification of ACK timeout is not an Atheros specific 
> feature. According to a quick skim over the source code in 
> drivers/net/wireless, besides ath5k and ath9k it's at least supported by 
> rt2x00, rtl818x and maybe zd1211.
> 
> I think the current hardware support is sufficient for a generic mac80211 
> solution. The exact interpretation of ACK timeout value is hardware specific, 
> so I propose a higher level API operating with link distance.
> 
> It consists of a new nl80211 parameter:
> [NL80211_ATTR_WIPHY_DISTANCE] = { .type = NLA_U32 },
> 
> The value of the parameter would be a link distance in meters, so after the 
> support is added to iw one could set the ACK timeout on a 3km link using:
> # iw phy0 set distance 3000
> 
> Another required change would be extending cfg80211_ops by functions 
> set_distance and get_distance. Calculation of appropriate ACK timeout (and in 
> the case of ath5k, also CTS timeout and slottime) for the distance would be 
> left to the driver (it's a trivial formula).
> 
> I can prepare the patches, if you think these extension would be acceptable. 
> Suggestions are welcome.
> 
> Lukas Turek

Hello Lukas,

I think that's a good idea indeed. I think the relationship between ACK
timeout, CTS timeout and slottime and distance should be common (ie
implemented at mac80211 level) since the formula is not so trivial to me
(at least, I've seen several formulas flying around). Then, each driver
needs to convert ACK timeout since the HW registers probably takes into
account some specific MAC hw time.

Moreover, the formula is not the same for 2.4 GHz and 5 GHz.

madwifi had a patch for automatically finding the best ACK timeout,
maybe it could be ported to mac80211 as well.

My 2 cents,
Benoit

Re: [RFC] API for setting ACK timeout

[Felix Fietkau]

Benoit PAPILLAULT wrote:
> Hello Lukas,
> 
> I think that's a good idea indeed. I think the relationship between ACK
> timeout, CTS timeout and slottime and distance should be common (ie
> implemented at mac80211 level) since the formula is not so trivial to me
> (at least, I've seen several formulas flying around). Then, each driver
> needs to convert ACK timeout since the HW registers probably takes into
> account some specific MAC hw time.
> 
> Moreover, the formula is not the same for 2.4 GHz and 5 GHz.
> 
> madwifi had a patch for automatically finding the best ACK timeout,
> maybe it could be ported to mac80211 as well.
That patch is a rather ugly hack which involves doing statistics on the
number of retransmissions while changing the distance setting. It has a
tendency to crank up the ack timeout whenever there is some loss or
interference on the link, thereby making the effects of the interference
even worse. I don't think this should be added to mac80211.
At some point, I will try to come up with an implementation for ath9k
which doesn't involve such voodoo, but instead compares the tx timestamp
of some data packets against the rx timestamp of ack packets. I don't
know if this will work, but IMHO it's worth a try.

- Felix

Re: [RFC] API for setting ACK timeout

[David Pufer]

Lukáš Turek <8an@...> writes:

> 
> Hi,
> 
> we discussed this in ath5k-devel, but it involves a mac80211 extension, so I'm 
> bringing it here.
> 
> Although Wi-Fi was designed for outdoor use, it's also sometimes used for long 
> distance outdoor links. However, long distance links require longer ACK 
> timeout, as packets travel "only" at the speed of light and every kilometer 
> adds almost 7 microseconds to the roundtrip. So for a driver to be usable 
> outdoors it has to permit setting ACK timeout from userspace.
> 
> Currently this is supported only by out-of-tree Madwifi driver for Atheros 
> hardware. However, modification of ACK timeout is not an Atheros specific 
> feature. According to a quick skim over the source code in 
> drivers/net/wireless, besides ath5k and ath9k it's at least supported by 
> rt2x00, rtl818x and maybe zd1211.
> 
> I think the current hardware support is sufficient for a generic mac80211 
> solution. The exact interpretation of ACK timeout value is hardware specific, 
> so I propose a higher level API operating with link distance.
> 
> It consists of a new nl80211 parameter:
> [NL80211_ATTR_WIPHY_DISTANCE] = { .type = NLA_U32 },
> 
> The value of the parameter would be a link distance in meters, so after the 
> support is added to iw one could set the ACK timeout on a 3km link using:
> # iw phy0 set distance 3000
> 
> Another required change would be extending cfg80211_ops by functions 
> set_distance and get_distance. Calculation of appropriate ACK timeout (and in 
> the case of ath5k, also CTS timeout and slottime) for the distance would be 
> left to the driver (it's a trivial formula).
> 
> I can prepare the patches, if you think these extension would be acceptable. 
> Suggestions are welcome.
> 
> Lukas Turek
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@...
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 
Hi list,
for more advanced devices such as Atheros multiband multiantenna radios more
additional settings should be available than 80211 driver permits. While talking
about Atheros devices and their use in different environments, not only ACK
timeouts and slottime are concern but also ACK rate, interference mitigation
settins, antenna diversity, antenna mode, calibration interval, LED settings and
more. Therefore, concurrently maintained drivers for Atheros devices
(Madwifi-project, OpenWRT Madwifi driver) are far more usable and tunable in
different environments than ath5k with nl80211. I think, based the ath5k list,
the simplest way would be exporting such device-specific special settings into
procfs or sysfs like Madwifi driver (/proc/sys/dev/wlanX/setting_knob). Then
setting of a special parameter would be simple sysctl or echoing a value into a
file in /proc.. 80211 layer should perform its primary job (e.g. beaconing,
authentication..) and don't care of setting device-specific parameters.
Regards
David Pufer

Re: [RFC] API for setting ACK timeout

[Joerg Pommnitz]

Felix Fietkau wrote:
> At some point, I will try to come up with an implementation for 
> ath9k which doesn't involve such voodoo, but instead compares 
> the tx timestamp of some data packets against the rx timestamp 
> of ack packets. 

Would this mean, that we could get per station ACK timeouts?
If so, this would be very useful in an IBSS network. In such an
environment one might talk to nodes whose distance to the sender
vary over a broad range. 
-- 
Regards 
Joerg 

__________________________________________________
Do You Yahoo!?
Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails. 
http://mail.yahoo.com 

Re: [RFC] API for setting ACK timeout

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 841 bytes --]

On Mon, 2009-11-30 at 00:39 -0800, Joerg Pommnitz wrote:
> Felix Fietkau wrote:
> > At some point, I will try to come up with an implementation for 
> > ath9k which doesn't involve such voodoo, but instead compares 
> > the tx timestamp of some data packets against the rx timestamp 
> > of ack packets. 
> 
> Would this mean, that we could get per station ACK timeouts?
> If so, this would be very useful in an IBSS network. In such an
> environment one might talk to nodes whose distance to the sender
> vary over a broad range. 

Not likely that _any_ hardware supports that, it'd have to modify the
timers all the time. I suppose some firmware _could_ support it, but
it's a huge complexity for extremely little gain. In any case, setting
it to the max would be sufficient for this case, give it a thought :)

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]