802.11p rate control

802.11p rate control

[Rostislav Lisovy]

Dear 802.11 experts;
Short introduction before the actual question:
Some of you have probably noticed my effort of bringing the 802.11p
support for the mainline Linux kernel. (Side note: I know that "802.11p"
is already part of the IEEE 802.11-2012 but calling it ".11p" makes it
easier to determine what am I actually talking about).
My main focus is on the ITS-G5 (ETSI EN 302 663 [1], ETSI TS 102 687
[2]), European car-to-x communication standard based on 802.11p. For
those who are further interested, my work might be found at
https://github.com/CTU-IIG/802.11p-linux/tree/its-g5_devel 

Back to the main purpose of this email. I am still unsure how to
implement the rate-control handling for the 802.11p. The indisputable
fact is that the mandatory rates each 802.11p compliant device has to
support are 3, 6, 12 Mbit/s (IEEE 802.11-2012 18.1.1) since we are using
the OFDM 10MHz channels (other OFDM datarates might be used as well).
The decision which datarate to use for TX should be done by some kind of
algorithm, probably running in the kernel. The question is how to do so
in a clean way.

The possible obstacles are:
* 802.11p will be used mainly for two independent C2X protocol stacks --
one is the European ETSI ITS-G5, the other one is the US WAVE (IEEE
1609). I assume that these two protocol stack implementations will
differ mainly in the user-space while the kernel part will be the same.
* ITS-G5 already speaks about the "default datarate" for different
channels ([1] 4.3, Table 2) -- i.e. 6 Mbit/s for channel no. 180; 12
Mbit/s for channel no. 178. This should be probably defined when
"joining the network" on a fixed channel.

The possible (first implementation) solution might be either to
implement some "dummy" rate control algorithm that will set a fixed
datarate only once (during "ocb join" command) or to use the Minstrel
while limiting the allowed datarate to be the lowest one; i.e.
    mand_rates = ieee80211_mandatory_rates(sband, scan_width);
    sta->sta.supp_rates[band] =
        find_first_bit(&mand_rates, sizeof(u32));

If I am not mistaken, it is not possible to live without an in-kernel
rate_control algorithm?
One interesting idea I got from one colleague is to implement the
algorithm logic in the user-space -- kernel would contain just a thin
shell controlled from the user-space (via netlink?). This is probably
not as insane as it may sound since the purpose of the rate-control
algorithm for 802.11p (at least for ITS-G5) is not to "maximize the
immediate throughput" but more like "shared medium congestion control",
which may require much slower frequency of a control loop.

I will appreciate your comments. 

Best regards;
Rostislav Lisovy

[1] http://www.etsi.org/deliver/etsi_en/302600_302699/302663/01.02.01_60/en_302663v010201p.pdf
[2] http://www.etsi.org/deliver/etsi_ts/102600_102699/102687/01.01.01_60/ts_102687v010101p.pdf

Re: 802.11p rate control

[Felix Fietkau]

On 2014-09-08 18:30, Rostislav Lisovy wrote:
> The possible obstacles are:
> * 802.11p will be used mainly for two independent C2X protocol stacks --
> one is the European ETSI ITS-G5, the other one is the US WAVE (IEEE
> 1609). I assume that these two protocol stack implementations will
> differ mainly in the user-space while the kernel part will be the same.
> * ITS-G5 already speaks about the "default datarate" for different
> channels ([1] 4.3, Table 2) -- i.e. 6 Mbit/s for channel no. 180; 12
> Mbit/s for channel no. 178. This should be probably defined when
> "joining the network" on a fixed channel.
> 
> The possible (first implementation) solution might be either to
> implement some "dummy" rate control algorithm that will set a fixed
> datarate only once (during "ocb join" command) or to use the Minstrel
> while limiting the allowed datarate to be the lowest one; i.e.
>     mand_rates = ieee80211_mandatory_rates(sband, scan_width);
>     sta->sta.supp_rates[band] =
>         find_first_bit(&mand_rates, sizeof(u32));
> 
> If I am not mistaken, it is not possible to live without an in-kernel
> rate_control algorithm?
> One interesting idea I got from one colleague is to implement the
> algorithm logic in the user-space -- kernel would contain just a thin
> shell controlled from the user-space (via netlink?). This is probably
> not as insane as it may sound since the purpose of the rate-control
> algorithm for 802.11p (at least for ITS-G5) is not to "maximize the
> immediate throughput" but more like "shared medium congestion control",
> which may require much slower frequency of a control loop.
I think doing this in userspace is overkill. minstrel should be able to
handle rate control for 802.11p just fine if you set up the supported
rates properly.

By the way, minstrel does not try to "maximize the immediate
throughput", it tries to maximize the ratio of throughput vs used
airtime, which should be good for 802.11p as well.

- Felix

Re: 802.11p rate control

[Johannes Berg]

On Mon, 2014-09-08 at 18:30 +0200, Rostislav Lisovy wrote:

> The possible (first implementation) solution might be either to
> implement some "dummy" rate control algorithm that will set a fixed
> datarate only once (during "ocb join" command) or to use the Minstrel
> while limiting the allowed datarate to be the lowest one; i.e.
>     mand_rates = ieee80211_mandatory_rates(sband, scan_width);
>     sta->sta.supp_rates[band] =
>         find_first_bit(&mand_rates, sizeof(u32));

That's pretty much already done anyway since you'd restrict the
supported rates to the ones that are, well, supported :)

So I don't think you need to do anything here except set up the station
correctly.


> If I am not mistaken, it is not possible to live without an in-kernel
> rate_control algorithm?
> One interesting idea I got from one colleague is to implement the
> algorithm logic in the user-space -- kernel would contain just a thin
> shell controlled from the user-space (via netlink?). This is probably
> not as insane as it may sound since the purpose of the rate-control
> algorithm for 802.11p (at least for ITS-G5) is not to "maximize the
> immediate throughput" but more like "shared medium congestion control",
> which may require much slower frequency of a control loop.

I'm not really convinced this is feasible, but in any case - are you
even communicating long enough with a single peer to make rate control
feasible?


Anyway - it seems to me that you're getting ahead of yourself. Shouldn't
you actually have a functioning datapath before worrying about rate
control? And for that you'll need station handling in mac80211, etc.

johannes

Re: 802.11p rate control

[Emmanuel Thierry]

Le 10 sept. 2014 à 10:50, Johannes Berg a écrit :

> On Mon, 2014-09-08 at 18:30 +0200, Rostislav Lisovy wrote:
> 
>> If I am not mistaken, it is not possible to live without an in-kernel
>> rate_control algorithm?
>> One interesting idea I got from one colleague is to implement the
>> algorithm logic in the user-space -- kernel would contain just a thin
>> shell controlled from the user-space (via netlink?). This is probably
>> not as insane as it may sound since the purpose of the rate-control
>> algorithm for 802.11p (at least for ITS-G5) is not to "maximize the
>> immediate throughput" but more like "shared medium congestion control",
>> which may require much slower frequency of a control loop.
> 
> I'm not really convinced this is feasible, but in any case - are you
> even communicating long enough with a single peer to make rate control
> feasible?
> 

The way i understand the problem, and as far as it is feasible, the rate-control wouldn't be done on the basis of a single peer-to-peer communication but globally according to the congestion of the shared media.

Most of messages on such link would be multicast or broadcast, in the typical use case where a vehicle/roadside station announces an accident or another danger to neighboring listeners. As a consequence, the main purpose of rate adaptation in this case would not be to ensure the delivery to a particular target, but the delivery to most available targets.


> 
> Anyway - it seems to me that you're getting ahead of yourself. Shouldn't
> you actually have a functioning datapath before worrying about rate
> control? And for that you'll need station handling in mac80211, etc.
> 

I don't know what is the exact status of the patchset in linux wireless. However we performed tests on the complete patchset published on github and didn't see major problems in terms of packet delivery.

Best regards.
Emmanuel Thierry