public inbox for iwd@lists.linux.dev
 help / color / mirror / Atom feed
From: James Prestwood <prestwoj@gmail.com>
To: "Denis Kenzior" <denkenz@gmail.com>,
	"Pedro André" <PEDA@bang-olufsen.dk>,
	"iwd@lists.linux.dev" <iwd@lists.linux.dev>
Subject: Re: [PATCH] add AllowRoaming station property
Date: Wed, 18 Oct 2023 07:56:35 -0700	[thread overview]
Message-ID: <222ec16a-6ee4-43a0-bb9d-17d258a0ba4f@gmail.com> (raw)
In-Reply-To: <76261973-a04e-488c-8fc0-a0f623c15af0@gmail.com>

Hi Denis,

On 10/18/23 7:32 AM, Denis Kenzior wrote:
> Hi James,
> 
>>
>> LGTM, I actually needed something along these lines for dynamically 
>> disabling roaming e.g. during a software upgrade or some time when 
>> networking is critical. Just hadn't gotten to it yet.
> 
> I'm curious about the use cases.  What were your thoughts on how this 
> should look like?
> 
> I imagine for things like firmware update you still have a set time 
> limit in which this upgrade should happen?

I wanted to remove the possibility that a roam could cause a network 
timeout during an update. In a perfect world network queries should be 
fault tolerant and retry, but in practice this isn't always the case. 
And to be honest this is probably less of an issue than network 
congestion/latency on the backend causing a problem.

I think any issues that could happen would be entirely related to the 
infrastructure but nevertheless if avoiding a roam temporarily makes for 
better reliability I'd vote to do it.

For example one problem we see infrequently, but it does happen, is 
complete loss of IP networking post roam. Disabling roams during an 
update would at least get the update finished before this potentially 
happens.

> 
> Right now I like Pedro's earlier proposal with the minimum throughput 
> guidance. I think we can go further and calculate the roaming RSSI 
> threshold based on the minimum throughput.  This would allow iwd to 
> ignore roaming until that minimum throughput can no longer be delivered. >
> If we need a bigger hammer, then we may want to consider using an 
> implementation similar to how Modem.Lockdown was implemented in oFono.

I'll check that out.

> 
> Regards,
> -Denis

  reply	other threads:[~2023-10-18 14:56 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-18 12:27 [PATCH] add AllowRoaming station property Pedro André
2023-10-18 12:51 ` James Prestwood
2023-10-18 14:32   ` Denis Kenzior
2023-10-18 14:56     ` James Prestwood [this message]
2023-10-18 14:20 ` Denis Kenzior
2023-10-19 11:55   ` Pedro André
2023-10-20 14:57     ` Denis Kenzior
2023-10-20 16:29       ` James Prestwood

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=222ec16a-6ee4-43a0-bb9d-17d258a0ba4f@gmail.com \
    --to=prestwoj@gmail.com \
    --cc=PEDA@bang-olufsen.dk \
    --cc=denkenz@gmail.com \
    --cc=iwd@lists.linux.dev \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox