Re: [calsify] Working Group Last Call: draft-ietf-calext-valarm-extensions-01

[Daniel Migault <[e-mail]>]

That is an interesting comment. I am not sure if it should be placed in the
main body of the document or in the security consideration section.

Yours,
Daniel


On Mon, Jul 13, 2020 at 3:33 PM Cyrus Daboo <[e-mail]> wrote:

> Hi Ken,
>
> --On Mon, 13 Jul 2020 14:31:56 -0400 Ken Murchison <[e-mail]>
> wrote:
>
> >> <mglt>
> >> It is probably due to my lake of expertise, but I have the impression
> >> the acknowledgment properties only works under some conditions.
> >> Typically, I imagine that devices not being connected, are hosting the
> >> VALARMS components locally, in which case, these devices will not
> >> consider the acknowledgment properties.
> >> Similarly, when devices are connected to a centralized calendar, I
> >> suppose - but might completely wrong - that the alarms are
> >> simultaneously sent to the various devices. The ability to switch off
> >> all alarms relies on the ability of these devices to be able to synch
> >> the calendar objects. I am wondering if most systems have a push
> >> mechanism to "switch off" the alarms on the other devices.
> >> </mglt>
> >
> >
> > The mechanism for "switching off" alarms on devices, is that each device
> > should sync the iCalendar resource with the server just prior to firing
> the
> > alarm.  If the VALARM contains an ACKNOWLEDGED property on/after the
> > trigger time, then the device should not fire the alarm.
>
> Actually that is not the typical case. Certainly devices should pre-check
> the ACKNOWLEDGED property before triggering the alarm, but in most cases
> that will not be set.
>
> The typical case has alarms triggering simulataneously on all the devices
> belonging to a user. Those will popup an alert on all devices. The user
> then
> acks the alert on one device. That device adds the ACKNOWLEDGED property
> and
> writes the event back to the server. The server then triggers a push
> notification to the other devices. The other devices sync the changed
> event.
> The other devices spot the presence of the ACKNOWLEDGED property and
> automatically dismiss the visual alert.
>
> It might be worth noting one operational consideration here: there is a
> "stampeding herd effect" caused by this ack behavior. Specifically, in
> enterprise enrvironments, meetings often occur at the start of an hour.
> Those meetings can often involve multiple attendees, each of whom may
> setup
> their own alarm. So servers will get hammered with lots of requests when
> the
> alarms trigger and start to get ack'd by the users. That gets multipled by
> the number of devices each user has, since those will receive a push
> notification and then sync the ack changes from the server.
>
> In our enterprise system, we saw very large spikes in requests on the
> hour,
> a smaller spike at 45 mins past the hour, and further smaller spikes at 15
> mins and 30 mins past the hour. There were typically large spikes at 9
> am/10
> am/11 am, smaller at 12 pm/1 pm (lunch time), then bigger again at 2 pm/3
> pm, and tailing off after that. These were all traced to the alarm ack
> behavior . In our case, the client defaults to setting up alarms 15 mins
> before a meeting (though many people change that to occur at the time of
> the
> meeting) - hence the noticeable spike at 45 mins past the hour. That,
> combined with meetings that start on the half-hour, give rise to the
> pattern
> we saw.
>
> I am not sure if this issue should be described in the spec, but it was
> definitely a performance/scaleability issue that had to be accounted for.
>
> > For disconnected devices, there is no solution that I'm aware of.
>
> Correct. The user would have to manually dismiss UI alerts on all
> disconnected devices.
>
> --
> Cyrus Daboo
>


-- 
Daniel Migault
Ericsson