Re: [dhcwg] Comments on draft-ietf-dhc-addr-notification-00

[Lorenzo Colitti <[e-mail]>]

The text in the working copy has been updated to reflect this thread.
See updated
text here
<https://wkumari.github.io/draft-wkumari-dhc-addr-notification/draft-ietf-dhc-addr-notification.html#name-registration-expiry-and-ref>.
Michael, Bernie, does that work?

There are a couple of other issues I just thought of.

First, clock skew and transmission delays might affect the algorithm.
Example:

   1. Server sends an RA with a lifetime of 600, but it is delayed by 300ms
   by congestion.
   2. After 60 seconds, server sends an RA with a lifetime of 540, which is
   not delayed by congestion. At this point the client will think the lifetime
   is still 541 seconds, and thus it might think that the lifetime "changed".

To avoid this we might want to change "changes the Valid Lifetime of an
existing address" to "changes the Valid Lifetime of an existing address by
more than 1% (to account for clock skew)".

Second: should we say that when the ADDR-REG-INFORM message is
retransmitted, the retransmitted packet SHOULD (or even MUST) contain the
current lifetime of the address, not the one in the original packet?
Rationale: If a client sends an update with a lifetime of 600s, and then
later retransmits the packet a few times, and the server only gets the
retransmit that happens 10s later, it would be good if the server received
a lifetime of 590s instead of 600s. Bernie, do you know of anything in the
DHCPv6 RFCs that say that retransmitted packets must be identical to the
original packet?

Thoughts?

On Sat, Aug 12, 2023 at 4:52 PM Jen Linkova <[e-mail]> wrote:

> On Fri, Aug 11, 2023 at 5:40 PM Bernie Volz <[e-mail]> wrote:
> >
> > How about "The client MUST periodically refresh addresses using the
> > logic described below"?That would clearly indicate how the refreshes
> > shall be scheduled,
> >
> >
> > I’d remove periodically.
>
> SGTM, the change will be integrated into the next version of the draft.
>
> >
> > - Bernie (from iPad)
> >
> > On Aug 11, 2023, at 7:34 PM, Jen Linkova <[e-mail]> wrote:
> >
> > On Fri, Aug 11, 2023 at 3:26 PM Bernie Volz <[e-mail]> wrote:
> >
> >
> > So you are saying that if host generates address with lifetime of 10m,
> only one refresh at 8m will be sent. Unless and if a PIO received.
> >
> >
> > Yes, exactly.
> >
> > Let's look at different cases:
> >
> > Case1: The network keeps sending RAs with constant valid lifetime for
> > the given PIO.
> >
> > Initial state: a hoist has no addresses.
> > t=0. A PIO with valid = 10m received. An address is formed and moved
> > to preferred state. The address has a lifetime of 10 mins, a
> > registration is sent, and the message includes the current preferred
> > and valid lifetimes (X mins and 10 mins). The next refresh is
> > scheduled to be sent in 8 mins.
> > All RAs received between t=0 and t=8 refresh the address's actual
> > lifetime, but do not trigger a new refresh message (as those messages
> > would have been scheduled *after* one which is scheduled already).
> > t = 8m.  As the host has been receiving RAs for that PIO with valid
> > lifetime = 10m, the actual lifetime (Y) is getting refreshed, so it's
> > 2mins  < Y < 10min.
> > The host sends a registration message (as it's already scheduled) with
> > the actual lifetime. NO new registration messages are scheduled at
> > that point.
> >
> > t < 8 + Y: a host would receive an RA  with the PIO with valid
> > lifetime = 10m. (otherwise the address becomes invalid, we are done).
> > That refreshes the actual lifetime (making it 10 mins again), and, as
> > per #1 from the proposed algorithm, would schedule a new refresh in
> > the next 8 mins.
> > etc.
> >
> > Case 2: The prefix disappeared from the network.
> > t = 0. The address was either formed (or an RA refreshed the lifetime
> > and triggered the refresh message). The actual address lifetime is
> > 10m.
> > The next message is scheduled in 8 mins.
> > t = 8m. The message is sent, informing the server that the address
> > currently has a valid lifetime of 2 mins.
> > t = 10m. The address is invalid. End of story.
> >
> > Case 3. The network needs to *reduce* the valid lifetime (e.g. for
> renumbering).
> > t = 0.  The address was either formed (or an RA refreshed the lifetime
> > and triggered the refresh message). The actual address lifetime is
> > 10m.
> > The next message is scheduled in 8 mins.
> > t = 4 mins (4 is just an example). A PIO received with valid = 4 mins.
> > It sets the address's actual valid lifetime to 4 min, and - as per #2
> > from the proposed algorithm, the next refresh should happen in 3.5
> > mins (t=7.5m), which is earlier than the currently scheduled message,
> > so the client reschedules it.
> > t = 7.5m. The registration message is sent, containing the *actual*
> > lifetime of the address (which is between 0.5 and 4 mins at that
> > moment).
> > .... the next PIO received (which must come before the address becomes
> > invalid) would cause another refresh message and schedule one in 3.5
> > mins.
> > Etc.
> >
> > Case 4. The network increases the valid lifetime for a PIO.
> > t = 0.  The address was either formed (or an RA refreshed the lifetime
> > and triggered the refresh message). The actual address lifetime is
> > 10m.
> > The next message is scheduled in 8 mins.
> > t = 4 mins (4 is just an example). A PIO received with valid = 24hrs.
> > it refreshes the actual lifetime of the address, setting it to 24 hrs,
> > but it doesn't reschedule the refresh message.
> > t = 8 mins. A refresh message is sent, informing the server that the
> > address is still there with the valid lifetime of 23hrs 56mins. No
> > other refresh messages are scheduled.
> > 8mins < t1 <24hrs: an RA received, which refreshes the lifetime,
> > triggers the refresh message and schedules the next one in 4hrs (as
> > 24hrs*0.8 > 4hrs).
> > t1 + 4hrs: A refresh message is sent, informing the server that the
> > address is still there with the valid lifetime of ..whatever it is ;)
> >
> > yes, if the valid lifetime is very short (which means a lot of RAs are
> > sent), the client might be refreshing too often - that's why we might
> > want  (as Lorenzo suggested) to set a lower limit as well.
> >
> > But what happens in case where lifetime is 24 hours? Then only one
> refresh will be sent (after 4 hours) unless a PIO is received?
> >
> >
> > Please keep in mind that the host would receive multiple (definitely
> > more than 3) RAs with the PIO during the valid lifetime interval.
> >
> > Example case (all times from t=0) when address generated with 24 hour
> lifetime. Registration sent. First refresh sent after 4 hours. And PIO sent
> after 12 hours to extend another 24.
> >
> > This re-registration happens here happens after 8 hours (when PIO
> received) - this is case 1.
> >
> >
> > So the 4 hour periodic refresh is not done?
> >
> >
> > Maybe we get rid of the 4 hour periodic refreshes altogether?? Or maybe
> these edge cases are just that and will show odd behavior.
> >
> >
> > It's not our goal to guarantee that the message is always sent at
> > least every 4 hrs. There is no practical difference between 4 hrs and
> > 8 hrs, as long as the message contains the up-to-date address's
> > lifetime (so the administrator knows "if the lifetime expired and we
> > haven't heard from the host - it's not there").
> > The reason to introduce the 4 hrs upper limit in the algorithm is that
> > many networks use the default valid lifetime value, which is 30 days.
> > So w/o 4 hrs limit the host would schedule the very first refresh in
> > 24 days, which makes the refresh useless.
> > Basically that X (X= 4) hrs shall be comparable with how long a client
> > would stay connected.
> >
> > I think adding something to the text that makes it clear that when a
> refresh expires, it is not automatically rescheduled. Only a PIO can
> reschedule (or initiate a new one). I still had the old model in mind and
> the statement "The client MUST periodically refresh addresses” implies
> periodicity and rescheduling when refresh expires?
> >
> >
> > How about "The client MUST periodically refresh addresses using the
> > logic described below"?That would clearly indicate how the refreshes
> > shall be scheduled,
> >
> >
> > On Aug 11, 2023, at 5:17 PM, Jen Linkova <[e-mail]> wrote:
> >
> >
> > On Fri, Aug 11, 2023 at 1:04 PM Bernie Volz <[e-mail]> wrote:
> >
> >
> > Hum … there’s still one case that concerns me … so I’m going to shot a
> hole in the algorithm.
> >
> >
> > If the lifetime is 2h and not being extended, a refresh will occur at
> 0.8*2h = 96 min, now lifetime that remains is 24 min, so refresh happens at
> 19.2 min with 4.8 min left, then again at 230 sec … so, refresh come very
> often while lifetime is running down (such as when a prefix is being
> deprecated).
> >
> >
> > Oh, what you found is not a hole in the algorithm, but us being lazy at
> wording.
> >
> > We did spend some time thinking about that case and explicitly made
> >
> > sure hosts DO NOT send updates more and more often,  but we didn't
> >
> > phrase it properly in the text ;(
> >
> > The idea behind "the refresh is scheduled when the address becomes
> >
> > valid (== created) and after that - ONLY when an RA is received. We
> >
> > phrased it as "the host updates the Valid Lifetime of an existing
> >
> > address" - so yes, the text kind of covers "counting a lifetime down
> >
> > in an absence of RA" but it wasn't the intention.
> >
> >
> > Thank you for pointing this out.
> >
> >
> > How about:
> >
> >
> > "The client MUST periodically refresh addresses. Each refresh is
> >
> > scheduled after AddrRegRefresh seconds, where AddrRegRefresh is min(4
> >
> > hours, 80% of the address's current Valid Lifetime). Refreshes SHOULD
> >
> > be jittered by +/- 10% to avoid synchronization.
> >
> >
> > Whenever the client creates an address or receives an RA which updates
> >
> > the Valid Lifetime of an existing address, then:
> >
> > 1. If no refresh is currently scheduled, it MUST register immediately
> >
> > and schedule a refresh.
> >
> > 2. If a refresh is currently scheduled, it MUST reschedule the
> >
> > existing refresh if this would result in the refresh being sooner than
> >
> > currently scheduled.
> >
> > "
> >
> >
> >
> > I wonder if solution is to schedule refreshes every min(lifetime, 4
> hours). And for client to track lifetime remaining at server and when the
> lifetime is extended (via PIO), client reschedules refresh if server’s
> remaining lifetime is less than 0.8 * min(server’s remaining lifetime,
> currently scheduled refresh time) and reschedules for that 0.8*min…?
> >
> >
> > Note that refresh when lifetime is 0 means to notify server address is
> no longer in use (or just leave it as server will expire anyway).
> >
> >
> > Note that client cannot just use its lifetime in the extended lifetime
> case as there could have been several extended lifetimes since last time
> server was refreshed; hence important to track what server has.
> >
> >
> > With your earlier case:
> >
> >
> > t=0 receive RA with lifetime 10m ==> schedule refresh at t=10m
> >
> > t=9 receive RA with lifetime 10m ==> client determines refresh needed at
> 0.8*min(1m, 1m)=48sec
> >
> >
> > t=9:48 client refreshes registration
> >
> >
> >
> > We could be more agressive and use 0.5 (renewal) factor here instead of
> 0.8 (rebinding). That would send the refresh at 9:30.
> >
> >
> > This probably falls apart for ultra short lifetimes (i.e., ~60 seconds
> or less).
> >
> >
> > - Bernie (from iPad)
> >
> >
> > On Aug 11, 2023, at 10:38 AM, Bernie Volz <[e-mail]> wrote:
> >
> >
> > Let’s go with your algorithm unless someone can come up with a
> situation where this doesn’t work.
> >
> >
> > Regarding minimum times, that’s a more difficult situation. Perhaps
> there’s something useful in what Michael pointed out to refresh things when
> there is traffic (keeping NCE entry hot)? Especially when a registration
> server previously replied indicating that it is using the information … and
> this should result in a single packet/client most times.
> >
> >
> > If specified, you need to make it clear that minimum lifetime is for
> registration purposes ONLY.
> >
> >
> > And perhaps use of this mechanism should be discouraged when short
> lifetimes are in use on a network? If DHCPv6 is otherwise not in use, then
> not setting O (and M) bit is administratively something to recommend. If
> DHCPv6 address assignment is used, one would assume that DHCPv6 lifetimes
> are short too, then having these transmissions is no different that what
> DHCPv6 would see (actually, it will be less as they are coming at 0.8 the
> valid lifetime instead of RENEWs at 0.5 the preferred lifetime).
> >
> >
> > And if you’re using short lifetimes, there will be frequent RA
> transmissions (while these me be multicast, they might not be). So, you’re
> already paying penalties (such as battery life) for that.
> >
> >
> > - Bernie (from iPad)
> >
> >
> > On Aug 10, 2023, at 6:20 AM, Bernie Volz <[e-mail]> wrote:
> >
> >
> > I do think that reconsidering the refresh when extending is the proper
> way to go … I had been trying to see if that could be avoided but it
> obviously cannot be. I think you may have a good algorithm in what you sent
> but will think a bit more on it.
> >
> >
> > - Bernie (from iPad)
> >
> >
> > On Aug 10, 2023, at 6:01 AM, Lorenzo Colitti <[e-mail]> wrote:
> >
> >
> > 
> >
> > On Tue, Aug 8, 2023 at 1:12 AM Bernie Volz <[e-mail]> wrote:
> >
> >
> > Well this would make this even more useless than it currently is as even
> devices that are using an address and were reporting may now not be in
> cases where shorter lifetimes are in use.
> >
> >
> > The -00/01 text was:
> >
> >
> > The client MUST refresh the registration every AddrRegRefresh seconds,
> where AddrRegRefresh is min(1/3 of the Valid Lifetime filed in the very
> first PIO received to form the address; 4 hours ).
> >
> >
> > And I don’t recall any WG discussion to reduce this as you’ve proposed …
> though we are discussing it now.
> >
> >
> >
> > Ah, yes. My mistake, I misread the min.
> >
> >
> >
> >
> > The client MUST refresh the registration every AddrRegRefresh seconds,
> where AddrRegRefresh is min(0.8 of the Valid Lifetime and 4 hours).
> However, the client MUST NOT send a refresh when this timer expires unless
> the Valid Lifetime was extended since the last registration or the Valid
> Lifetime is greater than 5 hours.
> >
> >
> >
> > I think this algorithm does not work in corner cases like the following:
> >
> >
> > t=0 receive RA with lifetime 10m ==> schedule refresh at t=8m
> >
> > ... no RAs received
> >
> > t=8m ==> client does not refresh because the lifetime was never extended
> >
> > t=9 receive RA with lifetime 10m ==> client does not schedule a refresh
> >
> > t=10 server believes address has expired, but actually it still has 9
> minutes left.
> >
> >
> > Jen and I spent a while thinking about various corner cases and came up
> with the following. This seems simple to implement and robust. Thoughts?
> >
> >
> > ==========
> >
> > The client MUST periodically refresh addresses. Each refresh is
> scheduled after AddrRegRefresh seconds, where AddrRegRefresh is min(4
> hours, 80% of the address's current Valid Lifetime). Refreshes SHOULD be
> jittered by +/- 10% to avoid synchronization.
> >
> >
> > Whenever the client creates an address or updates the Valid Lifetime of
> an existing address, then:
> >
> > 1. If no refresh is currently scheduled, it MUST register immediately
> and schedule a refresh.
> >
> > 2. If a refresh is currently scheduled, it MUST reschedule the existing
> refresh if this would result in the refresh being sooner than currently
> scheduled.
> >
> >
> > Discussion: this algorithm ensures that refreshes are not sent too
> frequently, while ensuring that the server never believes that the address
> has expired when it has not. Specifically:
> >
> > - If the network never changes the lifetime, or stops refreshing the
> lifetime, then only one refresh ever occurs. The address expires.
> >
> > - #1 ensures that any time the network changes the lifetime when no
> refresh is scheduled, the server will be informed of the correct lifetime.
> If the network does not change the address's lifetime, then the server
> already knows the correct lifetime and no update needs to be sent.
> >
> > - #2 ensures that if the network reduces the lifetime of the address,
> then the server will be informed of the new lifetime. If the network
> increases the lifetime of the address, the refresh will be sent at the
> previously scheduled time, and the server will be informed of the correct
> lifetime. From this point on, either the address expires (and the server is
> informed of when this will happen) or an RA increases the lifetime, in
> which case a refresh will be sent.
> >
> >
> > ==========
> >
> >
> > I still think we need a minimum lifetime somewhere - if a router sends
> PIOs with a lifetime of 3 minutes (and there are lots of home networks that
> do this), then the device will be sending 4 packets every 2.4 minutes.
> That's not terrible but it's still pretty bad for battery life.
> >
> >
> > Can we say that networks that want to receive address registrations on
> this SHOULD NOT use lifetimes less than, say, 10 minutes? Then we can say
> that the client MAY ignore lifetimes less than 10 minutes and treat them as
> if they were 10 minutes?
> >
> >
> > Cheers,
> >
> > Lorenzo
> >
> >
> > _______________________________________________
> >
> > dhcwg mailing list
> >
> > [e-mail]
> >
> > https://www.ietf.org/mailman/listinfo/dhcwg
> >
> >
> >
> >
> > --
> >
> > SY, Jen Linkova aka Furry
> >
> >
> >
> >
> > --
> > SY, Jen Linkova aka Furry
>
>
>
> --
> SY, Jen Linkova aka Furry
>