Network association algorithm

[Javier Cardona]

Dan,

> Any chance you could tighten up the timeout/backoff algorithm to not
> wait so long between tries?  A max of 5 - 7 seconds or so between
> DHCPDISCOVER tries should be a good enough hack for the moment...
> Sometimes it picks obscene values like 25 seconds.  On a wireless
> medium, it's just really, really likely the frame got lost somewhere
> rather and needs to be re-requested.

This can be done with the existing initial-interval option:

interface "msh0" {
  initial-interval 1;
  anycast-mac ethernet c0:27:c0:27:c0:27;
}

DHCPDISCOVER on msh0 to 255.255.255.255 port 67 interval 1
DHCPDISCOVER on msh0 to 255.255.255.255 port 67 interval 2
DHCPDISCOVER on msh0 to 255.255.255.255 port 67 interval 2
DHCPDISCOVER on msh0 to 255.255.255.255 port 67 interval 4
DHCPDISCOVER on msh0 to 255.255.255.255 port 67 interval 5
DHCPDISCOVER on msh0 to 255.255.255.255 port 67 interval 9
...

Javier



> > Cheers,
> >
> > Javier
> >
> > The patch:  https://cozybit1.dnsalias.org/~javier/patches/dhclient-3.0.5-anycast.patch
> >
> > On 5/9/07, Michail Bletsas <mbletsas at laptop.org> wrote:
> > > Javier,
> > >
> > > I think that your approach fits perfectly with our latest connection
> > > flowchart and I would like to see it implemented asap.
> > >
> > > M.
> > >
> > >
> > >
> > >
> > >
> > > "Javier Cardona" <javier at cozybit.com>
> > > 05/04/2007 02:39 PM
> > >
> > > To
> > > "John Watlington" <wad at laptop.org>
> > > cc
> > > "Dan Williams" <dcbw at redhat.com>, "Michail Bletsas" <mbletsas at laptop.org>,
> > > "OLPC Devel" <devel at laptop.org>
> > > Subject
> > > Re: Network association algorithm
> > >
> > >
> > >
> > >
> > >
> > >
> > > Hi John, Dan,
> > >
> > >
> > > After chatting with Dan I finally understood your flowchart (pardon my
> > > thickness,  I was having some nomenclature problems..).  I learned
> > > yesterday
> > > that:
> > >
> > >  1) "established MPPs" are MPPs with multiple mesh interfaces, at most one
> > > on
> > >  each channel 1,6 and 11.  They are also called "school servers" and will
> > > not
> > >  be moving around.
> > >
> > >  2) "ad-hoc MPPs" are xo's that act as MPPs, as portals they were
> > > originally conceived.
> > >
> > >  3) Addresses are assigned by DHCP because link local addresses cannot be
> > >  routed.  L3 routing is done by MPPs across mesh segments at different
> > >  channels.
> > >
> > > Based on this understanding, I would like to suggest a change in the way
> > > DHCP
> > > is used in your proposal.  The current flow is:
> > >
> > >        +           +
> > >       / \         / \
> > >      /   \ y     /   \ y
> > > ----+DHCP?+-----+ MPP?+----
> > >      \   /       \   /
> > >       \ /         \ /
> > >        + n         + n
> > >        |           |
> > >        +-----------+
> > >        |
> > >
> > > This approach separates IP address assignment (DHCP) and MPP detection and
> > > path
> > > selection.  I believe these two functions which can be combined in one:
> > >
> > > 1. xo sends a DCHP request to L2 address ANY_MPP.  This is a standard
> > > DHCPREQUEST sent to a unicast address.  The only thing "non-standard"
> > > would be
> > > done at the dhcp client:  this DHCPREQUEST would have the L2 anycast
> > > address, the L3 broadcast address and would be injected at L2 using
> > > the linux packet interface.
> > >
> > > 2. MPP assigns an IP address and sends a DHCPACK to the L2 address that
> > > was in
> > > the DHCPREQUEST.  That's vanilla DHCP server.
> > >
> > > 3. The xo knows the DHCPACK comes from an MPP because it's a response from
> > > a
> > > request sent to the ANY_MPP address.
> > >
> > > Advantages:
> > >
> > > 1. Faster configuration.
> > > 2. No broadcast+anycast traffic, only anycast.
> > > 3. Replaces non-standard MPPREQs with standard DHCP
> > >
> > > This model can also be used for ad-hoc MPPs.  In that case ad-hoc MPPs
> > > would
> > > return gateway and DNS information but would not assign an IP address.
> > >
> > > What do you think?
> > >
> > > Javier
> > >
> > >
> > >
> > >
> >
> >
>
>


-- 
Javier Cardona
cozybit Inc.
p 415 974 6770
f 415 974 6771
c 415 630 0627
e javier at cozybit.com