Subject: [Webpush] Quick comment on webpush reliability

From: Adam Roach <[email-masked]>
Date: Wed, 16 Jul 2014 14:09:19 -0500

Looking over draft-thomson-webpush-http2-00, I find the final statement 
to be something of a zinger: "[A]pplications that rely on the content of 
push messages being delivered MUST ensure that they provide other means 
of delivering messages to devices."

I suspect we're going to want to have a pretty broad set of 
considerations around this statement. Without clarification, 
implementors are likely to read it as requiring them to *also* use some 
other data update mechanism, unrelated to push (which, as the 
introduction points out, is an energy-intensive proposition).

So we're probably going to want to add some mechanism to push that helps 
clients deal with this set of circumstances. For example, if there were 
an ability for a client to actively query for a version, tag, or "last 
updated date", it would be able to detect missed messages through the 
parsimonious use of polling (which could be done periodically and/or 
opportunistically when the radio is already in use). This allows 
applications to avoid doing their own (out-of-sync) polling.

It seems that the 'Prefer: wait="0"' mechanism on the monitor channel 
would be a good place to add this functionality (although I'll admit 
that I can't figure out what the currently intended purpose of that 
mechanism is, so I might be either interfering with some other intended 
feature or possibly stating something that you thought should be obvious 
to the reader).

On a separate topic: I think the description of channel URIs as bearer 
tokens is pretty weak right now. This seems like a good place for 
normative language.

/a

---

From: Martin Thomson <[email-masked]>
Date: Wed, 16 Jul 2014 13:57:33 -0700

On 16 July 2014 12:09, Adam Roach <[email-masked]> wrote:
> Looking over draft-thomson-webpush-http2-00, I find the final statement to
> be something of a zinger: "[A]pplications that rely on the content of push
> messages being delivered MUST ensure that they provide other means of
> delivering messages to devices."
>
> I suspect we're going to want to have a pretty broad set of considerations
> around this statement.

Indeed.  This was included only as an observation that push can't be
the *only* way that an application acquires updated state.

Part of the goal here is to minimize hard state commitment
requirements on push servers.  I'm not saying that a server couldn't
provide some sort of indication that a client is up to date, which
could certainly use any reasonable mechanism.  That includes
If-Modified-Since and If-None-Match and all the other HTTP cache-based
mechanisms in addition to what we might like to invent.

The problem is that if we *require* that a push server do something,
then that is a hard constraint of the likes I've intentionally avoided
so far.  I know for a fact that some of these systems are incapable of
doing that, and even those that do can't make any completely solid
guarantees anyway.  At least not with the reliability you want or
need.

This needs work to ensure that we don't create an invitation to go off
and write a parallel update channel, or to have applications polling
or other self-defeating practices.  For most applications, it's
perfectly easy to have sync code that runs at startup, resume, or when
notified of a push service outage.  What I want to do is avoid having
the push service be responsible for facilitating that.  As an
application developer, you know your data/state/needs better than any
middlebox.

> tokens is pretty weak right now. This seems like a good place for normative
> language.

Yes, the document hasn't undergone the usual hardening in this regard.
At this stage, I'm assuming our audience is familiar with prior art on
the subject.  I'll note that other issues on locator/identifier
separation and all that nonsense have been raised on the W3C list
already.

Thanks for the feedback; I'm tracking these here:
https://github.com/martinthomson/drafts/issues

---

From: Costin Manolache <[email-masked]>
Date: Wed, 16 Jul 2014 14:34:22 -0700

AFAIK a typical case is a mobile network /  firewall or device policy
preventing the push channel.
One option would be for the push API to notify the apps if the push
connection is available.

Costin

On Wed, Jul 16, 2014 at 1:57 PM, Martin Thomson <[email-masked]>
wrote:

> to
> considerations
> normative
> _______________________________________________
> Webpush mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/webpush
>

---

From: Martin Thomson <[email-masked]>
Date: Wed, 16 Jul 2014 15:20:48 -0700

> preventing the push channel.

A typical case of what?

> One option would be for the push API to notify the apps if the push

Feedback on service availability is an important API feature, yes.

---

From: Costin Manolache <[email-masked]>
Date: Wed, 16 Jul 2014 15:25:21 -0700

> > preventing the push channel.

Of applications that rely on push having a need for alternative means of
updating.

Costin

---

From: Martin Thomson <[email-masked]>
Date: Wed, 16 Jul 2014 15:53:40 -0700

> Of applications that rely on push having a need for alternative means of

I'm not sure that we want to do too much to recognize those scenarios
in this context.  That might do more to encourage bad behaviour.
Those people that have to deal with those sorts of outages know that
already.

I'm more concerned here with transitory outages, devices that power
off, and those sorts of failures.

---

From: Costin Manolache <[email-masked]>
Date: Wed, 16 Jul 2014 18:13:01 -0700

> Those people that have to deal with those sorts of outages know that

By "device policy" I mean things like roaming or low battery mode, or user
choice to disable background push.
Even if we don't recognize them - they are the main failure mode for push
on
android and probably other devices.

> off, and those sorts of failures.

I can't comment on this - my experience is with servers that store
messages, so
poweroff/offline is expected behavior.

Costin

---

From: nero <[email-masked]>
Date: Thu, 31 Jul 2014 15:23:11 +0100

More than reliability, push messaging is often mistakenly considered "real
time". One one hand this is great since systems like GCM helped create this
impression, however due to mobile network architectures and such messages
are sometimes delayed for a certain amount of time.
Push systems should be reliable, but cannot ensure real timeliness.
I am not sure about the MUST keyword in that sentence, but we could provide
use cases and examples.
For instance email sync could sync-poll every hour, and reset the poll
alarm every time a push is received or so...

  francesco

-- 
Prudence is a rich, ugly old maid courted by Incapacity