Subject: [dhcwg] RE: meta thoughts on m/o bits

From: "Soliman, Hesham" <[email-masked]>
Date: Fri, 20 May 2005 15:36:53 -0400

Hi Bernie, 

 > > => You can try, but my concern is about how often you're 
 > going to try.
 > > If there are bits that say whether you should try or not and those 
 > > bits are not set (i.e. no DHCP server in the network), why 
 > > would you try?
 >  
 > This means that the wiresless operators will get more revenue from
 > Ralph!
 > 
 > If the wireless operator isn't using DHCP (or only using stateless),
 > there's no reason they can't charge for that (stateful) traffic.

=> :) I don't want them to charge users for Ralph's implementation :)
But seriously, charging is one thing, inefficient use of power is 
another serious problem which can actually reduce revenue because
a device doesn't go dormant long enough and runs out of battery 
instead of using that battery power for what the user actually wants
to do.

Hesham

 > 
 > This is the reason why having one (or two) bits in the RA to indicate
 > whether DHCP should be run are useful. But, those bits are advisory
 > only.
 > 
 > - Bernie
 > 
 > > -----Original Message-----
 > > From: [email-masked] [mailto:[email-masked]] On 
 > > Behalf Of Soliman, Hesham
 > > Sent: Friday, May 20, 2005 3:15 PM
 > > To: Ralph Droms (rdroms)
 > > Cc: [email-masked]; [email-masked]
 > > Subject: RE: meta thoughts on m/o bits
 > > 
 > > 
 > > 
 > >  > No one is suggesting DHCP is the "default address configuration
 > >  > mechanism".  Let's *please* not go down that discussion path...
 > > 
 > > => some parts of the discussion were hinting at that, that's 
 > > why I said "side note". I'm glad you're not suggesting that.
 > > 
 > >  > 
 > >  > More comments in line.
 > >  > 
 > >  > On Fri, 2005-05-20 at 14:50 -0400, Soliman, Hesham wrote:
 > >  > > In some scenarios there is a danger in the following approach:
 > >  > > - hosts boots
 > >  > > - looks for DHCP server, doesn't find one
 > >  > > - Keeps looking every couple of minutes
 > >  > 
 > >  > A client is free to use some other timeout (2 hours instead of 2
 > >  > minutes?) if it chooses.  See sections 5, 14 and 17.1.2 of 
 > >  > RFC 3315.  I
 > >  > imagine standards bodies for specific environments (3GPP2?) 
 > >  > might well
 > >  > mandate different retransmit timeouts, for example, to conserve
 > >  > bandwidth or power.
 > > 
 > > => It's unrealistic to assume that. An SDO might suggest that but
 > > how does an implementation know it's in a 3GPP/2 or some other 
 > > wireless network, or even ethernet? An implementation might just 
 > > see a PPP driver or an ethernet driver. That says nothing about 
 > > the underlying technology.
 > > 
 > >  > 
 > >  > > This leads to inefficient use of power and network resources 
 > >  > > in some wireless devices. A more efficient way to do 
 > things is 
 > >  > > to indicate in the RA whether the host should even try to find
 > >  > > a DHCP server. I find the current description in 2461/2bis
 > >  > > sufficient, dynamic and provides enough granularity to allow
 > >  > > hosts to look for what they need (i.e. addresses or 
 > >  > "other" config).
 > >  > 
 > >  > Yes, a bit indicating whether to expect a DHCP service at 
 > >  > all might be
 > >  > useful ... although I, as an implementor, might be tempted 
 > > to try the
 > >  > DHCP service anyway in certain circumstances; suppose 
 > there are no
 > >  > advertised prefixes from which to assign SLAAC addresses?
 > > 
 > > => You can try, but my concern is about how often you're 
 > going to try.
 > > If there are bits that say whether you should try or not and those 
 > > bits are not set (i.e. no DHCP server in the network), why 
 > > would you try?
 > > 
 > > Hesham
 > > 
 > >  > 
 > >  > > As a side note, we must not force DHCP to be a 
 > default address 
 > >  > > configuration mechanism in IPv6. Stateless address 
 > > config actually
 > >  > > provides a very useful and timely way of configuring 
 > addresses 
 > >  > > for mobile nodes.
 > >  > > 
 > >  > > Hesham
 > >  > > 
 > >  > > 
 > >  > >  > -----Original Message-----
 > >  > >  > From: [email-masked] 
 > [mailto:[email-masked]]On 
 > >  > >  > Behalf Of
 > >  > >  > Ralph Droms
 > >  > >  > Sent: Friday, May 20, 2005 2:34 PM
 > >  > >  > To: [email-masked]; [email-masked]
 > >  > >  > Subject: Re: meta thoughts on m/o bits
 > >  > >  > 
 > >  > >  > 
 > >  > >  > Well...DHCPv6 doesn't have any better mechanism 
 > for announcing
 > >  > >  > availability of a server than does DHCPv4 (which is to 
 > >  > say "none").
 > >  > >  > There has not been an identified need to push an 
 > >  > announcement of DHCP
 > >  > >  > server availability out to clients.
 > >  > >  > 
 > >  > >  > Section 14 of RFC 3315 specifies the retransmission 
 > >  > behavior for DHCP
 > >  > >  > clients.  When that behavior is interpreted for Solicit 
 > >  > messages in
 > >  > >  > section 17.1.2, the result is that the DHCP client 
 > > continues to
 > >  > >  > retransmit Solicit messages at low frequency (once 
 > >  > every 2 minutes)
 > >  > >  > forever.  Therefore, the client will eventually 
 > contact the 
 > >  > >  > DHCP service
 > >  > >  > when a server becomes available.
 > >  > >  > 
 > >  > >  > - Ralph
 > >  > >  > 
 > >  > >  > On Fri, 2005-05-20 at 13:53 -0400, Thomas Narten wrote:
 > >  > >  > > > This proposal looks better and easy to 
 > > understand. However,
 > >  > >  > > > if we just rely on timeout for concluding the 
 > >  > >  > unavailabiliy of DHCP server,
 > >  > >  > > > how does the client re-invoke DHCP if the DHCP 
 > server is 
 > >  > >  > available later in 
 > >  > >  > > > time? I think we need one bit to inform the clients 
 > >  > about the
 > >  > >  > > > availabilty of DHCP
 > >  > >  > > > services in the network.
 > >  > >  > > 
 > >  > >  > > I would assume that DHC has mechanisms for 
 > >  > discovering when DHC
 > >  > >  > > servers come on line. I.e., the client just sits quietly 
 > >  > >  > in background.
 > >  > >  > > 
 > >  > >  > > Sure, an RA bit could also signal the availability of 
 > >  > a new server,
 > >  > >  > > but I would first like to be convinced that the existing 
 > >  > >  > default DHC
 > >  > >  > > mechanism isn't good enough for handling this 
 > case (better 
 > >  > >  > not to have
 > >  > >  > > multiple ways of acheiving the same result).
 > >  > >  > > 
 > >  > >  > > Thomas
 > >  > >  > > 
 > >  > >  > > 
 > >  > >  > 
 > >  > 
 > > 
 > --------------------------------------------------------------------
 > >  > >  > > IETF IPv6 working group mailing list
 > >  > >  > > [email-masked]
 > >  > >  > > Administrative Requests: 
 > >  > > https://www1.ietf.org/mailman/listinfo/ipv6
 > >  > > > 
 > >  > 
 > > 
 > --------------------------------------------------------------------
 > >  > > 
 > >  > > 
 > >  > 
 > > 
 > --------------------------------------------------------------------
 > >  > > IETF IPv6 working group mailing list
 > >  > > [email-masked]
 > >  > > Administrative Requests: 
 > > https://www1.ietf.org/mailman/listinfo/ipv6
 > > > 
 > --------------------------------------------------------------------
 > > > 
 > > > ===========================================================
 > > > This email may contain confidential and privileged material 
 > > for the sole use
 > > >  of the intended recipient.  Any review or distribution by 
 > > others is strictly
 > > >  prohibited.  If you are not the intended recipient please 
 > > contact the sender
 > > >  and delete all copies.
 > > > ===========================================================
 > > 
 > > 
 > --------------------------------------------------------------------
 > > IETF IPv6 working group mailing list
 > > [email-masked]
 > > Administrative Requests: 
https://www1.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Jari Arkko <[email-masked]>
Date: Sat, 21 May 2005 07:57:00 +0300

>instead of using that battery power for what the user actually wants
I tend to agree with Hesham that we should attempt to design
our protocols so that unnecessary periodic probing over wireless
is minimized. One thing that should be kept in mind is that most
people want their devices to be always on and reachable, but yet
they might actually use them for something only a very small
fraction of the time. Even a tiny amount of traffic during the
inactive period may thus result in a relatively large impact
when you compare it to actual useful traffic. This in turn
translates to battery lifetimes and cost for the users.

--Jari