Subject: Re: [Webpush] FW: New Version Notification for draft-thomson-webpush-protocol-00.txt

From: Costin Manolache <[email-masked]>
Date: Tue, 12 May 2015 10:58:06 -0700

It is hard to support ordering at scale - we would prefer that ordering is
not guaranteed.
But we support de-duplication and retries.

Costin

On Wed, Apr 29, 2015 at 12:24 PM, DRUTA, DAN <[email-masked]> wrote:

> Hi Martin,
>
> I think we can address the relative priority in the web push draft at
> minimum with some clarifications on use cases and some of the requirements.
> Much like I tried to explain in my example and you expanded with the device
> nap scenario.
> If NICE proposal gets support in http WG I don't see any reason to
> reinvent the wheel but as of now I believe your draft is expired.
> At least we should determine how important of a feature this is.
>
> Dan
>
> -----Original Message-----
> From: Martin Thomson [mailto:[email-masked]]
> Sent: Wednesday, April 29, 2015 11:57 AM
> To: DRUTA, DAN
> Cc: Brian Raymor (MS OPEN TECH); [email-masked]
> Subject: Re: [Webpush] FW: New Version Notification for
> draft-thomson-webpush-protocol-00.txt
>
> On 29 April 2015 at 10:12, DRUTA, DAN <[email-masked]> wrote:
> > 1. Prioritization
> [...]
> > Is the expectation that the app server will send them in the right
> sequence and the push server will use a FIFO (first in first out) queue?
>
> The draft really doesn't say, partly because we didn't discuss it
> much, partly because I think that we'd want some flexibility.  I've
> opened an issue on this in our issue tracker so that we don't forget
> this.
>
> > Priority is a fairly basic requirement and I hope it can get handled in
> a header so it can be consistently enforced by the push service.
>
> Prioritization is a concern if there are multiple messages to deliver
> at the same time.  This happens most often when a device comes back
> from a short nap (as mobile devices do all the time).  With a small
> number of messages, this might not be a big deal, but if there is a
> backlog to clear, it could be.  I have a draft on signaling priorities
> that could be used in this context:
> https://tools.ietf.org/html/draft-thomson-http-nice-02
>
> Do you think that we need to address this in a basic protocol
> specification, or can it rely on other specifications.
>
> > 2. Message deduplication and retries.
>
> Yes, reliability is hard.  The intent is to have the application mark
> messages and perform deduplication if it does resending, especially
> within the TTL period that the push service promises.
>
> In terms of the protocol, there is a proposal for message replacement
> that might reduce the need for some of this, but Brian, Elio and I
> decided that we'd let this draft stabilize before talking about that
> feature: https://github.com/unicorn-wg/webpush-protocol/pull/12
> _______________________________________________
> Webpush mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/webpush
>

---

From: Martin Thomson <[email-masked]>
Date: Fri, 15 May 2015 16:12:40 -0700

> But we support de-duplication and retries.

I don't think that any proposal has actually *required* a specific
ordering.  What the nice proposal suggests is that different policies
be adopted with respect to waking idle devices.

Ordering might be possible. Either way, the effort would be entirely
voluntary: prioritization indicates what an application wants, which
might correspond to superior performance if the push service could
respect that value, but ultimately nothing should break if priority is
ignored.  We also have to recognize that applications will sometimes
(often?) act in their own self-interest and that their prioritization
choices might not be chosen with global optimization in mind.

I think that de-dupe and retries are orthogonal to this.

---

From: Costin Manolache <[email-masked]>
Date: Fri, 15 May 2015 19:07:49 -0700

Agreed, having priority is good at least to indicate relative importance of
different messages
from the same app. If the app is on a battery-powered device - we may use
the priority to
decide if we'll wake up the device or it can be delayed a bit.

Costin