From: Emmanuel Thierry <ml@sekil.fr>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: Rostislav Lisovy <lisovy@gmail.com>,
linux-wireless@vger.kernel.org, burak.simsek@volkswagen.de,
s.sander@nordsys.de, sojkam1@fel.cvut.cz,
jan-niklas.meier@volkswagen.de, thierry.ernst@yogoko.fr,
oyunaash@gmail.com, laszlo.virag@commsignia.com
Subject: Re: 802.11p rate control
Date: Wed, 10 Sep 2014 11:19:46 +0200 [thread overview]
Message-ID: <AD4CAB87-0EF1-4915-A576-82C359159416@sekil.fr> (raw)
In-Reply-To: <1410339003.2761.2.camel@jlt4.sipsolutions.net>
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
prev parent reply other threads:[~2014-09-10 9:27 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-08 16:30 802.11p rate control Rostislav Lisovy
2014-09-08 16:56 ` Felix Fietkau
2014-09-10 8:50 ` Johannes Berg
2014-09-10 9:19 ` Emmanuel Thierry [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=AD4CAB87-0EF1-4915-A576-82C359159416@sekil.fr \
--to=ml@sekil.fr \
--cc=burak.simsek@volkswagen.de \
--cc=jan-niklas.meier@volkswagen.de \
--cc=johannes@sipsolutions.net \
--cc=laszlo.virag@commsignia.com \
--cc=linux-wireless@vger.kernel.org \
--cc=lisovy@gmail.com \
--cc=oyunaash@gmail.com \
--cc=s.sander@nordsys.de \
--cc=sojkam1@fel.cvut.cz \
--cc=thierry.ernst@yogoko.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.