Re: [PATCH] Add dhcp timeout and anycast config options

[Dan Williams <dcbw redhat com>]

On Thu, 2008-08-07 at 16:06 +0100, Sjoerd Simons wrote:
> On Tue, Aug 05, 2008 at 04:09:18PM -0400, Dan Williams wrote:
> > On Tue, 2008-08-05 at 19:52 +0100, Sjoerd Simons wrote:
> > > On Tue, Aug 05, 2008 at 02:05:51PM -0400, Dan Williams wrote:
> > > > On Tue, 2008-08-05 at 18:10 +0100, Sjoerd Simons wrote: 
> > > > > > I'd rather not have configurable DHCP timeouts in this manner because for
> > > > > > non-mesh cases, the DHCP timeout never needs to change.  If we can set the
> > > > > > DHCP timeout for mesh operations in the activation request like the old code
> > > > > > did, that would be preferable.
> > > > > 
> > > > > I guess i could do that. But that would mean mixing device configuration
> > > > > and ip configuration for mesh devices, which doesn't seem the right way to
> > > > > me. I don't really see any harm in exposing this functionality for all
> > > > > devices (although maybe we should clamp it to a certain min and max value)?
> > > > 
> > > > Well, the mesh code is specific for OLPC, and the DHCP timeouts there were
> > > > tuned to the specific mesh cases and behavior that we had with
> > > > OLPC.
> > > 
> > > Well hopefully the mesh code will become less OLPC specific soon. As
> > > mesh-support is now in the mainline linux kernel and should work with all
> > > mac80211s devices. But indeed this change is indeed a tad specific to the OLPC
> > > usecase.
> > > 
> > > > Furthermore, DHCP timeouts shouldn't need to be changed in general
> > > > anyway.  People always try to get the DHCP timeout raised for wireless
> > > > stuff, but the fact is that if you're not connected in 45 seconds, the
> > > > driver has a bug, your key is wrong, or you're waaay out of range.
> > > > There is no good reason to allow user-configurable DHCP timeouts at this
> > > > point.
> > > > 
> > > > Just because the option can be tweaked doesn't mean it should in 99% of
> > > > cases.
> > > 
> > > Just because you can set the property in the D-Bus interface doesn't mean
> > > you have to :) But yeah, i'll rewrite this to not expose the dhcp timeout
> > > setting in the general ip4 config properties.
> > > 
> > > What are your feelings about the anycast property, as it's probably even
> > > more specific to OLPC?
> > 
> > My feeling is that anycast should stay specific to the OLPC case, since it's
> > an OLPC implementation detail.  We can put some stuff internally to
> > make anycast and the 'initial-interval' stuff easier for the OLPC mesh
> > device, but I don't think we need to expose it.
> > 
> > Maybe the better approach here is to create an "olpc-mesh" setting type
> > which would be used in the NMSettingConnection's ->type field.  This
> > type would only be valid when used with the OLPC mesh device class and
> > when NM saw this connection type in a connection, it would know to
> > activate the mesh device if needed.
> 
> That's what i'm doing indeed. I've added a new type for the olpc mesh devices,
> which only allows  connection of the mesh type.
> 
> > Thus, you could add some OLPC specific stuff like anycast address, and
> > whether to start MPP on that particular connection or not to the
> > setting.  I'm not sure what the implications of having two separate
> > connections here are (one for the 802.11 wifi device and one for the
> > mesh device) and how they'd interact, but this approach might work.
> 
> Having two seperate connections isn't a big issue. The only constraint you
> have is that both devices need to be on the same frequency (as they use the
> same radio), which in practise means that if your wifi connect hops between
> AP's on different channels, your MPP will jump frequency with it.
> 
> This is something the olpc NM client needs to take into account when
> configuring these devices, but not something NM specifically needs to know
> about.
> 
> > The real logic in the OLPC NM builds was to do the handoffs between the
> > WiFi and mesh interfaces, but they each had their own individual
> > configuration in the end.  Since each NMConnection provides individual
> > configuration that might be a way to go with this.
> 
> Yeah most of the logic in OLPC NM 0.6 is basically gone for NM 0.7 as it
> properly supports multiple active connections. NM 0.7 for OLPC currently just
> knows about the special OLPC mesh device and has two extra options in the ipv4
> settings for the dhcp timeout and the anycast address.
> 
> All other logic will move into sugar.
> 
> > So what actual mesh-specific tunables (besides anycast address) would
> > you anticipate needing?
> 
> For the ip connectivity, only anycast and a short dhcp timeout are needed.
> Although i wouldn't say these are mesh-specific tunables, there might be
> non-mesh situations where you want to use them. I also don't really see the
> problem in exposing these properties in the ipv4 settings on D-Bus, most
> clients should just leave them alone.

We're just coming at this from different perspectives.  The problem for
me is that this is exposed API without a clear use-case at this time.
Thus, it's API that we need to preserve going forward, and people will
do weird things with API if you make it available.  Thus, to control the
maintenance burden you keep the feature set smaller until you actually
need the feature.

> But anyway, i'm quite happy to disagree on those last points and provide some
> patches which only add infrastructure in the NM core and keep the actual
> configuration in olpc specific bits.

Yep, that sounds good for now.

Dan