Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-solmaxrt-update-00.txt

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 1 Feb 2013 16:32:59 +0000

Good catch about INF_MAX_RT ... it should be the same as SOL_MAX_RT (by default).

Also, regarding the timeout and "receive" issue ... while waiting an hour for an Advertise (or Reply if Rapid-Commit is enabled) is unlikely to yield anything different than waiting a "reasonable" short time (a few minutes). There may be cases were a packet is held up at several places during a routing issue or while ND occurs, but this would be unlike to be very long.

I think how long the client leaves the "receive" active is more of an implementation issue. I would think it broken to not wait at least about a minute (probably this should be tied to the default hop limit (3x) -- not for the client's link-local packet but for the relay/server and server and server/relay/client path and some small number of seconds for server processing latency) . But beyond that, it likely doesn't matter. If the default hop limit is still 64, that argues for a value from 128 - 196 seconds at most.

For clients where leaving the receive (and socket?) active has negative implications, they may want to shut it down when waiting long for the next retransmission.

The important detail here is that the retransmissions are reduced. It is less critical how long the client waits for packets between retransmissions after some reasonable interval.

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dmitry Anipko
Sent: Thursday, January 31, 2013 2:23 PM
To: Bud Millwood; Sten Carlsen
Cc: [email-masked]; Andre Kostur; Ted Lemon
Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-solmaxrt-update-00.txt

To Bud's question: I meant the type of energy cost Andre & Sten referred to. From my observations, network adapters which require significantly more energy when they listen, are not uncommon.

So if there is a "low hanging fruit", which is to simply add one phrase to the solmaxrt-update that in reality doesn't require behavior change of any servers today, but allows some client devices to save energy, why not take it. Are there any objections?

Along the same lines, I'd suggest changing default for INF_MAX_RT similarly to SOL_MAX_RT (or at least say the host MAY choose to do so), with the same rationale - DHCP server is not replying after several frequent retransmissions, so what's the point of trying as frequently. 

To Ted's point, I think a larger overhaul of DHCP to make it more power friendly is an interesting idea to explore, though it will probably take noticeably more time and ignite passionate debates (which are good, but again, take more time to reach consensus :)).

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Bud Millwood
Sent: Thursday, January 31, 2013 6:21 AM
To: Sten Carlsen
Cc: Andre Kostur; [email-masked]; Dmitry Anipko; Ted Lemon
Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-solmaxrt-update-00.txt

Sten, thanks for that real-world example, I've learned something.

- Bud

On Thu, Jan 31, 2013 at 1:27 PM, Sten Carlsen <[email-masked]> wrote:
>
> On 31/01/13 13:18, Andre Kostur wrote:
>
> A second consideration is whether the energy-constrained device needs 
> to keep a radio alive in order to listen for the incoming UDP?
>
> Usually there will be a strict timing so the power for the radio is 
> minimized by only listening at specific times. The master example is 
> GSM that can sleep for 2.12 seconds and then listen for 300µs. Other 
> energy restricted devices must be designed likewise or burn far too much energy.
>
> Generally from this perspective fixed/predictable windows makes sense, 
> synchronize events and save more energy.
>
>
> On Thu, Jan 31, 2013 at 2:53 AM, Bud Millwood 
> <[email-masked]>
> wrote:
>
> On Thu, Jan 31, 2013 at 3:20 AM, Andre Kostur <[email-masked]> wrote:
>
> Not directly related to this draft (as this is a consideration after 
> the device obtains some addresses), but if one of these 
> restricted-power devices wished to be able to do Reconfigure, how 
> would that work?
>
> For that matter, what about any other scenario where we could adjust 
> the time spent using a socket in order to reduce energy?
>
> My question for Dmitry is: if you're not waiting on a socket, aren't 
> you waiting on something? And is it actually likely that it costs more 
> energy (CPU cycles) to wait on an unconnected socket than any other 
> wait mechanism?
>
> I just want to make sure we don't go off solving a problem that 
> doesn't actually exist. My understanding is that for long-term TCP 
> socket use on a mobile device, the correct way to do it is to adjust 
> the socket properties to minimize keepalive traffic. I believe that 
> Google provides Push Notification for Android using TCP, with the 
> socket settings tweaked to use almost no battery at all. And that's a 
> connected socket.
>
> For UDP, I can't see how a wait on the socket would use any extra CPU 
> cycles at all. But if you have some data, or even theoretical 
> references to such a problem, I'd be interested in reading about it.
>
> - Bud
>
> On Wed, Jan 30, 2013 at 6:10 PM, Ted Lemon <[email-masked]> wrote:
>
> On Jan 30, 2013, at 8:24 PM, Dmitry Anipko 
> <[email-masked]>
> wrote:
>
> So, if practically all servers reply with responses (if they reply at
> all) within seconds/minutes (e.g. current max RT fixed in the original
> 3315 - 120s + random deviation), and given the client will eventually 
> retry anyway, I'm trying to understand whether there is indeed a 
> strong reason for a client to wait for an hour.
>
> I suspected this was the issue you had in mind.   I think it would make
> sense to add something to the draft that addresses this issue.
>
>
>
> --
> Andre Kostur
> Distinguished Software Architect & Engineer
> P: 604-678-2864
> E: [email-masked]
> Toll-Free: 1-800-877-1856
>
>
> F: 604-678-2864
> VoIP: sip:[email-masked]
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg
>
>
>
> --
> Best regards
>
> Sten Carlsen
>
> No improvements come from shouting:
>        "MALE BOVINE MANURE!!!"
>
>
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg
>
_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Dmitry Anipko <[email-masked]>
Date: Fri, 1 Feb 2013 22:59:40 +0000

Agree with everything you wrote. I think several minutes waiting would be fine, and I understand there may be good reasons for such waiting interval (as opposed to hour).

If there is a general agreement on these 2 adjustments (allowed waiting period cap and INF_MAX_RT default), how do we move forward - Ralph, can these be included in the next revision of the draft?

Thank you.

-----Original Message-----
From: Bernie Volz (volz) [mailto:[email-masked]] 
Sent: Friday, February 01, 2013 8:33 AM
To: Dmitry Anipko; Bud Millwood; Sten Carlsen
Cc: [email-masked]; Andre Kostur; Ted Lemon
Subject: RE: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-solmaxrt-update-00.txt

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Bud Millwood
Sent: Thursday, January 31, 2013 6:21 AM
To: Sten Carlsen
Cc: Andre Kostur; [email-masked]; Dmitry Anipko; Ted Lemon
Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-solmaxrt-update-00.txt

- Bud

---

From: Sten Carlsen <[email-masked]>
Date: Sat, 02 Feb 2013 02:04:58 +0100

Bud, you're welcome.

I have given this a bit more thought, in GSM (as an example) the window
for beginning to listen for paging/traffic is about 600ns wide, so this
must be handled by the base station buffering those messages until the
next time it knows the device will listen for paging. That will also
make it possible to collect other messages for the same transmission.
Between pagings only the 32kHz clock is on, everything else including
the main clock is shut down to conserve energy and must be turned on and
fired up to look for pagings/receiving stuff, you don't do that if it
can be avoided, way too costly in energy.

Precision like a few hundred nanoseconds will never be possible in
normal network equipment so don't try.

Ensuring that there is slack in the timing to allow for the delay of a
few seconds would be good though.

On 31/01/13 15:21, Bud Millwood wrote:
>> minimized by only listening at specific times. The master example is GSM
>> that can sleep for 2.12 seconds and then listen for 300µs. Other energy
>> restricted devices must be designed likewise or burn far too much energy.
>>
>> On Thu, Jan 31, 2013 at 2:53 AM, Bud Millwood <[email-masked]>
>> wrote:
>>
>> On Jan 30, 2013, at 8:24 PM, Dmitry Anipko <[email-masked]>
>> wrote:
>>
>> So, if practically all servers reply with responses (if they reply at all)
>> within seconds/minutes (e.g. current max RT fixed in the original 3315 -
>> 120s + random deviation), and given the client will eventually retry anyway,
>> I'm trying to understand whether there is indeed a strong reason for a
>> client to wait for an hour.
>>

-- 
Best regards

Sten Carlsen

---

From: Ralph Droms <[email-masked]>
Date: Fri, 1 Feb 2013 21:07:42 -0500

(resending to dhcwg mailing list)

> If there is a general agreement on these 2 adjustments (allowed waiting period cap and INF_MAX_RT default), how do we move forward - Ralph, can these be included in the next revision of the draft?

Adding INF_MAX_RT makes sense.

In my opinion, the right thing to say about waiting for a response is something vague, to the effect of "A client is not expected to listen for a response during the entire period between transmission of Solicit or Information-Request messages."

- Ralph

---

From: Dmitry Anipko <[email-masked]>
Date: Sat, 2 Feb 2013 02:52:11 +0000

>> A client is not expected to listen for a response during the entire period between transmission of Solicit or Information-Request messages

Looks good to me. 

Thanks.

-----Original Message-----
From: Ralph Droms [mailto:[email-masked]] 
Sent: Friday, February 01, 2013 6:08 PM
To: Dmitry Anipko
Cc: Bernie Volz (volz); Bud Millwood; Sten Carlsen; [email-masked]; Andre Kostur; Lemon Ted
Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-solmaxrt-update-00.txt

- Ralph

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Sat, 2 Feb 2013 04:10:46 +0000

Fine by me too.

- Bernie

---

From: VithalPrasad Gaitonde <[email-masked]>
Date: Thu, 14 Feb 2013 19:13:46 -0800

Apparently, some relay agents/switches can be configured to relay packets
based on the amount of time the client has been trying (elapsed time
option). Similar language exists for the behavior of the DHCP server.

>From RFC 3315 section 22.9 -
Servers and Relay Agents use the data value in this option (elapsed time)
   as input to policy controlling how a server responds to a client
   message.  For example, the elapsed time option allows a secondary
   DHCP server to respond to a request when a primary server has not
   answered in a reasonable time.

When the client retransmits at every 1 hour interval, does the client reset
the elapsed time option to 0. If yes, with the above mentioned behavior of
relay agents and servers, the single retransmission of SOLICIT or INFORM
will turn out inadequate.
Also, given the unreliability of UDP, doing only one retransmission of the
message every hour (beyond the first hour) may lead to situations where the
server does not see the request and the client has to wait for another hour
to get an IPv6 address or options.

Instead of making just a single retransmission at every 1 hour interval,
the client should make at least a couple of retransmissions to increase the
reliability of getting an IPv6 address or options from the server.

Thanks,
Prasad
On Fri, Feb 1, 2013 at 8:10 PM, Bernie Volz (volz) <[email-masked]> wrote:

> >>> A client is not expected to listen for a response during the entire
> period between transmission of Solicit or Information-Request messages
> >
> > Looks good to me.
> >
> > Thanks.
> >
> > Subject: Re: [dhcwg] I-D Action:
> draft-ietf-dhc-dhcpv6-solmaxrt-update-00.txt
> >
> >> Agree with everything you wrote. I think several minutes waiting would
> be fine, and I understand there may be good reasons for such waiting
> interval (as opposed to hour).
> >>
> >> If there is a general agreement on these 2 adjustments (allowed waiting
> period cap and INF_MAX_RT default), how do we move forward - Ralph, can
> these be included in the next revision of the draft?
> >>
> >> Thank you.
> >
> > In my opinion, the right thing to say about waiting for a response is
> something vague, to the effect of "A client is not expected to listen for a
> response during the entire period between transmission of Solicit or
> Information-Request messages."
> >
> > - Ralph
> >

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 15 Feb 2013 22:44:37 +0000

(I guess I should now start saying "WG co-chair hat off" ...)

Interesting points.

The elapsed time option only supports 16-bits and is in 100ths of a second, so it will max out at 655.35 seconds (under 11 minutes).

As these are a 'retransmission' and so the XID would be the same and the elapsed time should reflect the time since the client started (obviously maxing out at a value of 0xffff as documented in RFC 3315).

Regarding the single packet issue ... I see:

1.       Let it be. If the original retransmissions up this point didn't work, what's the chance that it will work now? And a single packet should generally be OK. Though there may be some ND implementations that drop a packet they can't send instead of holding onto at least that one packet and that might cause things to fail 'forever' (the server-to-client or relay-to-client ND entry would expire before the next packet arrives).

2.       Have the client could 'restart' the Solicit process instead of using the longer time as a cap to the retransmission delay. But this means that the client would send restart sending at the normal backoff intervals and that makes the clients (if there are a lot) very chatty in total - which is what we wanted to prevent. This would also mean a new XID and new elapsed time base.

3.       Complicate the retransmission algorithm to allow some small number (2 or 3) packets in a "shorter" interval after 'long' retransmission interval (this is what you suggested). Probably these should occur well within the typical ND cache expiration interval.

4.       Something else? (Document that not retaining a packet per destination when needing ND is a bad idea.)

2 may be the most attractive as it is much simpler (and means this document would define an MRD for Solicit too). But the long delay between retransmissions leading up to the maximum may also suffer from the issue mentioned in #1, so #3 may have the best merit.

-          Bernie

From: [email-masked] [mailto:[email-masked]] On Behalf Of VithalPrasad Gaitonde
Sent: Thursday, February 14, 2013 10:14 PM
To: Bernie Volz (volz)
Cc: Bud Millwood; Dmitry Anipko; Ralph Droms; [email-masked]; Andre Kostur; Lemon Ted
Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-solmaxrt-update-00.txt

Apparently, some relay agents/switches can be configured to relay packets based on the amount of time the client has been trying (elapsed time option). Similar language exists for the behavior of the DHCP server.

When the client retransmits at every 1 hour interval, does the client reset the elapsed time option to 0. If yes, with the above mentioned behavior of relay agents and servers, the single retransmission of SOLICIT or INFORM will turn out inadequate.
Also, given the unreliability of UDP, doing only one retransmission of the message every hour (beyond the first hour) may lead to situations where the server does not see the request and the client has to wait for another hour to get an IPv6 address or options.

Instead of making just a single retransmission at every 1 hour interval, the client should make at least a couple of retransmissions to increase the reliability of getting an IPv6 address or options from the server.

Thanks,
Prasad
On Fri, Feb 1, 2013 at 8:10 PM, Bernie Volz (volz) <[email-masked]<mailto:[email-masked]>> wrote:
Fine by me too.

- Bernie

On Feb 1, 2013, at 9:52 PM, "Dmitry Anipko" <[email-masked]<mailto:[email-masked]>> wrote:

> From: Ralph Droms [mailto:[email-masked]<mailto:[email-masked]>]
> Cc: Bernie Volz (volz); Bud Millwood; Sten Carlsen; [email-masked]<mailto:[email-masked]>; Andre Kostur; Lemon Ted
> On Feb 1, 2013, at 5:59 PM 2/1/13, Dmitry Anipko <[email-masked]<mailto:[email-masked]>>
> wrote:
>
_______________________________________________
dhcwg mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Dmitry Anipko <[email-masked]>
Date: Sat, 16 Feb 2013 03:11:50 +0000

My understanding is that (2) would be against one of the motivations for the draft - reduce load on servers, as you pointed out.

So I agree (3) would be better, if at all something needs to be done for this issue.

From: Bernie Volz (volz) [mailto:[email-masked]]
Sent: Friday, February 15, 2013 2:45 PM
To: VithalPrasad Gaitonde
Cc: Bud Millwood; Dmitry Anipko; Ralph Droms; [email-masked]; Andre Kostur; Lemon Ted
Subject: RE: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-solmaxrt-update-00.txt

Interesting points.

-          Bernie

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of VithalPrasad Gaitonde
Sent: Thursday, February 14, 2013 10:14 PM
To: Bernie Volz (volz)
Cc: Bud Millwood; Dmitry Anipko; Ralph Droms; [email-masked]<mailto:[email-masked]>; Andre Kostur; Lemon Ted
Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-solmaxrt-update-00.txt

Thanks,
Prasad

- Bernie

---

From: VithalPrasad Gaitonde <[email-masked]>
Date: Wed, 27 Feb 2013 00:12:23 +0530

Agree that 3 has the best merit. In terms of number of retransmissions, it
would be preferable to go with as many retransmission (about 8?) as would
fit in a 2 minute interval (i.e. the older SOL_MAX_RT value).
Since existing deployments work with the 2 minute retransmission cycle,
this will ensure that subsequent retransmissions (beyond the first hour)
are successful.

So the proposal is - the first retransmission cycle is for 1 hour with
exponentially increasing time between retransmissions. Every subsequent
retransmission cycle which will occur after a gap of 1 hour will last for a
2 minute duration.

On Sat, Feb 16, 2013 at 8:41 AM, Dmitry Anipko
<[email-masked]>wrote:

>  My understanding is that (2) would be against one of the motivations for
> the draft – reduce load on servers, as you pointed out. ****
>
> ** **
>
> So I agree (3) would be better, if at all something needs to be done for
> this issue.****
>
> ** **
>
> *From:* Bernie Volz (volz) [mailto:[email-masked]]
> *Sent:* Friday, February 15, 2013 2:45 PM
> *To:* VithalPrasad Gaitonde
>
> *Cc:* Bud Millwood; Dmitry Anipko; Ralph Droms; [email-masked]; Andre
> Kostur; Lemon Ted
> *Subject:* RE: [dhcwg] I-D Action:
> draft-ietf-dhc-dhcpv6-solmaxrt-update-00.txt****
>
>  ** **
>
> (I guess I should now start saying “WG co-chair hat off” …)****
>
> ** **
>
> Interesting points.****
>
> ** **
>
> The elapsed time option only supports 16-bits and is in 100ths of a
> second, so it will max out at 655.35 seconds (under 11 minutes).****
>
> ** **
>
> As these are a ‘retransmission’ and so the XID would be the same and the
> elapsed time should reflect the time since the client started (obviously
> maxing out at a value of 0xffff as documented in RFC 3315).****
>
> ** **
>
> Regarding the single packet issue … I see:****
>
> **1.       **Let it be. If the original retransmissions up this point
> didn’t work, what’s the chance that it will work now? And a single packet
> should generally be OK. Though there may be some ND implementations that
> drop a packet they can’t send instead of holding onto at least that one
> packet and that might cause things to fail ‘forever’ (the server-to-client
> or relay-to-client ND entry would expire before the next packet arrives).
> ****
>
> **2.       **Have the client could ‘restart’ the Solicit process instead
> of using the longer time as a cap to the retransmission delay. But this
> means that the client would send restart sending at the normal backoff
> intervals and that makes the clients (if there are a lot) very chatty in
> total – which is what we wanted to prevent. This would also mean a new XID
> and new elapsed time base.****
>
> **3.       **Complicate the retransmission algorithm to allow some small
> number (2 or 3) packets in a “shorter” interval after ‘long’ retransmission
> interval (this is what you suggested). Probably these should occur well
> within the typical ND cache expiration interval.****
>
> **4.       **Something else? (Document that not retaining a packet per
> destination when needing ND is a bad idea.)****
>
> ** **
>
> 2 may be the most attractive as it is much simpler (and means this
> document would define an MRD for Solicit too). But the long delay between
> retransmissions leading up to the maximum may also suffer from the issue
> mentioned in #1, so #3 may have the best merit.****
>
> ** **
>
> **-          **Bernie****
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]<[email-masked]>]
> *On Behalf Of *VithalPrasad Gaitonde
> *Sent:* Thursday, February 14, 2013 10:14 PM
> *To:* Bernie Volz (volz)
> *Cc:* Bud Millwood; Dmitry Anipko; Ralph Droms; [email-masked]; Andre
> Kostur; Lemon Ted
> *Subject:* Re: [dhcwg] I-D Action:
> draft-ietf-dhc-dhcpv6-solmaxrt-update-00.txt****
>
> ** **
>
> option). Similar language exists for the behavior of the DHCP server.****
>
>  ****
>
> From RFC 3315 section 22.9 - ****
>
>    answered in a reasonable time.****
>
>  ****
>
> When the client retransmits at every 1 hour interval, does the client
> reset the elapsed time option to 0. If yes, with the above mentioned
> behavior of relay agents and servers, the single retransmission of SOLICIT
> or INFORM will turn out inadequate.****
>
> to get an IPv6 address or options.****
>
>  ****
>
> reliability of getting an IPv6 address or options from the server.****
>
>  ****
>
> Thanks,****
>
> Prasad****
>
> ****
> - Bernie****
> https://www.ietf.org/mailman/listinfo/dhcwg****
>
> ** **
>