Re: [Webpush] When UA should send an acknowledgement?

[Benjamin Bangert <[e-mail]>]

I'm in support of at-least-once processing, so the ack would occur last per
the DOM API. The difference would be that the DOM spec should require
ack even if decryption fails or the SW fails for some reason.

On Wed, Jun 8, 2016 at 12:38 AM, Martin Thomson
<[e-mail]> wrote:
> I'm sorry, I'm confused by your message.  I can't decide if you want
> at-least-once, or at-most-once.  End-to-end ack, i.e., ack after
> successful processing, is in support of at-least-once, which I think
> is consistent with other decisions we've made in the overall design.
>
> On 8 June 2016 at 15:15, Benjamin Bangert <[e-mail]> wrote:
>> On Tue, Jun 7, 2016 at 9:36 PM, Martin Thomson <[e-mail]> wrote:
>>> On 8 June 2016 at 13:17, Benjamin Bangert <[e-mail]> wrote:
>>>> For our implementation, we will actually never send more notifications
>>>> until all sent ones are ack'd. This means if a message is malformed or
>>>> causes a UA error in a UA that actually follows the DOM spec, it will
>>>> never get a notification again (except the notification it won't ack).
>>>
>>>
>>> This is fine, as long as you regard unacknowledged messages that you
>>> thought were delivered as poisonous after a certain amount of time (or
>>> retries, if you do that).  If you follow that advice, then progress
>>> will eventually be made.
>>
>> This recommendation isn't in the WebPush spec. By mandating that the UA
>> MUST ack every message it's clear that failure to ack a message should
>> result in redelivery attempts.
>>
>> If it's intended that a UA does not need to ack every message, the WebPush
>> spec should be updated to reflect that. I could see a PS reasonably
>> considering messages dead if other messages were ack'd or some other
>> command came over the connection such that the server knew that
>> the client is alive and likely processed it.
>>
>> Automatically ack'ing a message in this manner for the PS has as many
>> problems if not more than requiring the UA to ack every message though.
>> It also introduces a lot of complexity into the PS and may result in very
>> long message delivery times should a UA get bogged down with many
>> improperly encrypted messages.
>>
>>>
>>> I expect that Costin will agree with you, but we've discussed this in
>>> the past.  The problem here is that an acknowledgment from the user
>>> agent doesn't constitute a useful signal.  You have moved the problem
>>> to a second middle-man.  When the user agent acknowledges prior to
>>> processing the message, how will the application know that it was
>>> processed?  Can you guarantee that?  When the browser crashes, your
>>> message is still lost.
>>
>> Why not change the DOM spec to indicate that if a message was
>> processed and failed for some reason it should still be ack'd?
>>
>> If the same message consistently crashes the browser, I would expect
>> the browser to track that fact and avoid the message again in the future.
>>
>> Clearly we have the choice of guaranteeing that a message will be
>> processed at-most-once, or at-least-once, since a crash immediately
>> after processing could stop the ack from making it back. If the desire
>> is at-most-once, then the UA should ack immediately upon receipt of
>> the message (or the PS can consider it ack'd if a PING frame is
>> returned after sending a message, etc.).
>>
>> The Push DOM spec seems to favor the at-least-once model, in which
>> case it would be appropriate for the UA to always ack a message even
>> if it decrypts improperly, or the SW throws an exception, etc.
>>
>>>
>>> The only way for this to be a good signal is to have the
>>> acknowledgment be end-to-end.
>>>
>>> (p.s., I don't know if your assertion is true or not.  I don't think
>>> that it matters.  I should know that code, but it's an absolute rats
>>> nest, despite Kit's recent efforts at cleanup.)