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

From: VithalPrasad Gaitonde <[email-masked]>
Date: Wed, 23 Jan 2013 10:05:37 +0530

Hi Ralph,

This draft proposes to increase SOL_MAX_RT from 2 minutes to 1 hour.
Can you please clarify what is the expected behavior of the client with
this -
Is the client expected to send a SOLICIT every 1 hour and wait for a server
response for the next hour (timeout).
or is the client expected to send a SOLICIT every 1 hour but timeout after
2 minutes.

My understanding is the former but need confirmation.

Also, I expect that the proposal is that in the first hour when the client
connects to the network, the retransmission during this first hour are as
governed by section 14 of RFC 3315 i.e. the client does retransmissions
with increasing timeout values (starting with min of 1 second) till a max
timeout of 1 hour. Please confirm.

Thanks,
Prasad

On Fri, Dec 14, 2012 at 7:59 AM, <[email-masked]> wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>  This draft is a work item of the Dynamic Host Configuration Working Group
> of the IETF.
>
>         Title           : Modification to Default Value of SOL_MAX_RT
>         Author(s)       : Ralph Droms
>         Filename        : draft-ietf-dhc-dhcpv6-solmaxrt-update-00.txt
>         Pages           : 5
>         Date            : 2012-12-13
>
> Abstract:
>    This document updates RFC 3315 by redefining the default value for
>    SOL_MAX_RT and defining an option through which a DHCPv6 server can
>    override the client's default value for SOL_MAX_RT with a new value.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-solmaxrt-update
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-solmaxrt-update-00
>
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg
>

---

From: VithalPrasad Gaitonde <[email-masked]>
Date: Fri, 25 Jan 2013 22:05:03 +0530

Can someone please clarify on the below mentioned issues.

On Wed, Jan 23, 2013 at 10:05 AM, VithalPrasad Gaitonde
<[email-masked]>wrote:

> Is the client expected to send a SOLICIT every 1 hour and wait for a
> server response for the next hour (timeout).
>>  This draft is a work item of the Dynamic Host Configuration Working
>> Group of the IETF.
>>

---

From: Andre Kostur <[email-masked]>
Date: Fri, 25 Jan 2013 08:48:24 -0800

My interpretation of Sections 14 and 17.1.2 of RFC 3315 plus this
draft suggests that the client does all of the stuff it used to do,
but continues to extend the timeout out to 1 hour.  So it retries at
1, 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024, 2048, 3600, 3600...
seconds (modified by the random calculation).  The phrasing of RFC
3315 suggests that the client is valiantly waiting for an Advertise
(or Reply for Rapid Commit) through the entire time.

Of course, the 3600 may be modified by the server sending back the
option which sets that time to a different value.

On Fri, Jan 25, 2013 at 8:35 AM, VithalPrasad Gaitonde
<[email-masked]> wrote:
> On Wed, Jan 23, 2013 at 10:05 AM, VithalPrasad Gaitonde <[email-masked]>
> wrote:
>>
>> Hi Ralph,
>>
>> governed by section 14 of RFC 3315 i.e. the client does retransmissions with
>> increasing timeout values (starting with min of 1 second) till a max timeout
>> of 1 hour. Please confirm.

--
Andre Kostur

---

From: Dmitry Anipko <[email-masked]>
Date: Mon, 28 Jan 2013 07:35:36 +0000

>>The phrasing of RFC

While I agree this is one of the possible interpretations, is there a particular language which explicitly specifies this behavior?

Given that initially client retries with the interval of seconds, is it a reasonable assumption that any server implementation would reply within seconds or immediately to a client request (or not reply to that particular request at all), and hence if there was no reply - the client eventually re-transmits its message?

Thanks.

________________________________________
From: [email-masked] [[email-masked]] on behalf of Andre Kostur [[email-masked]]
Sent: Friday, January 25, 2013 8:48 AM
To: VithalPrasad Gaitonde
Cc: [email-masked]
Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-solmaxrt-update-00.txt

---

From: Ted Lemon <[email-masked]>
Date: Wed, 30 Jan 2013 11:57:36 +0000

> While I agree this is one of the possible interpretations, is there a particular language which explicitly specifies this behavior?

What Andre said is correct.   Section 17.1.2 of RFC3315 describes this in detail.

---

From: Dmitry Anipko <[email-masked]>
Date: Wed, 30 Jan 2013 19:17:19 +0000

Thanks Ted. The text in section 17.1.2 was written when SOL_MAX_RT was set at 120s. While this may be what the text says verbatim, it is not immediately clear, whether it is reasonable to extrapolate the same exact meaning to the case where SOL_MAX_RT is set to 1h. What scenario would be broken, if the client waited for server reply only for e.g. 120s after each retransmission every hour?

---

From: Ted Lemon <[email-masked]>
Date: Wed, 30 Jan 2013 19:54:49 +0000

> Thanks Ted. The text in section 17.1.2 was written when SOL_MAX_RT was set at 120s. While this may be what the text says verbatim, it is not immediately clear, whether it is reasonable to extrapola…

Ah, I see the question you are asking.   The current answer is that in principle, you have to be listening the whole time, but I'm curious to hear you explain why you think this is a problem.   I think I can guess, but I'd like you to tell us, because personal experience is more important than theory.

---

From: Dmitry Anipko <[email-masked]>
Date: Thu, 31 Jan 2013 01:24:02 +0000

For some devices, which are energy constrained, doing infinite wait on the network given that they are going to retransmit anyway (and will get a response fast if the server is back online) doesn't seem like the best use of their constrained resources. The actual cost depends on the device design - for some devices/types of links it may be higher than for others.

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.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 31 Jan 2013 02:10:10 +0000

> 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 wi…

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.

---

From: Andre Kostur <[email-masked]>
Date: Wed, 30 Jan 2013 18:20:52 -0800

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?

-- 
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]

---

From: Bud Millwood <[email-masked]>
Date: Thu, 31 Jan 2013 11:53:39 +0100

> restricted-power devices wished to be able to do Reconfigure, how

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

---

From: Andre Kostur <[email-masked]>
Date: Thu, 31 Jan 2013 04:18:16 -0800

A second consideration is whether the energy-constrained device needs
to keep a radio alive in order to listen for the incoming UDP?

F: 604-678-2864

---

From: Sten Carlsen <[email-masked]>
Date: Thu, 31 Jan 2013 13:27:19 +0100

> 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.

-- 
Best regards

Sten Carlsen

No improvements come from shouting:
       "MALE BOVINE MANURE!!!"

---

From: Ted Lemon <[email-masked]>
Date: Thu, 31 Jan 2013 12:50:13 +0000

If you guys are interested in exploring this issue, why not write up a problem statement?   There's certainly no technical reason why a DHCP server can't send reconfigures within a specified time window, but obviously the current spec doesn't say anything about this.

---

From: Sten Carlsen <[email-masked]>
Date: Thu, 31 Jan 2013 14:34:42 +0100

I am not sure it is worth the effort, every system will have its own
timings and idiosyncrasies, making something general that will fit most
is unlikely.
I just mentioned this to clarify the discussion a bit.

-- 
Best regards

Sten Carlsen

---

From: Ted Lemon <[email-masked]>
Date: Thu, 31 Jan 2013 13:43:09 +0000

On Jan 31, 2013, at 8:34 AM, Sten Carlsen <[email-masked]>
 wrote:
> I am not sure it is worth the effort, every system will have its own timings and idiosyncrasies, making something general that will fit most is unlikely.

I don't know if it's worth the effort either; perhaps we can simply say that mobile devices do not support Reconfigure unless they have really big batteries.   But if there is some desire to support reconfigure on mobile devices, it might be worth doing this.   Mobile devices typically have very accurate clocks; there is no particular reason why a solution can't be specified.

---

From: Bud Millwood <[email-masked]>
Date: Thu, 31 Jan 2013 15:21:14 +0100

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:
> 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

---

From: Dmitry Anipko <[email-masked]>
Date: Thu, 31 Jan 2013 19:22:37 +0000

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

- Bud

On Thu, Jan 31, 2013 at 1:27 PM, Sten Carlsen <[email-masked]> 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.
>