Niceness or urgency of messages

[martinthomson]

@DanDruta notes that prioritization can be important. This is true.

Maybe look at somehow integrating https://tools.ietf.org/html/draft-thomson-http-nice-02

[brianraymor]

First, we need to clarify whether there are scenarios that require priorities to be included in the base specification:

@DanDruta wrote:

As I went through the draft I wasn't able to understand how the push service will handle message prioritization (for the same subscription). 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 scenario I have in mind is a social network application that can push news alerts and incoming chat notifications. I would expect the chat notification to have a higher priority than other notifications. If the app server sends notifications as they happen, it is only the push service that will be able to act based on some form of prioritization indicator. 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.

@martinthomson responded:

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

[brianraymor]

Once we have clarity on scenarios and requirements and evaluated the importance of this feature, then we can consider designs.

@martinthomson has proposed nice-02 for the scenario above.

@darshakthakore proposed:

Would it make sense to use the Prefer header instead of the TTL header. This would allow carrying prioritization info for messages (the prioritization is only relative to the application server's own set of messages) to be carried in the Prefer header (e.g. Prefer: priority=5, wait=10). Also the wait 0 can be used to indicate the equivalent of TTL 0 or we can even define a new preference token.

@martinthomson responded:

Generally speaking, I believe Prefer to be better suited to requesting variations in request handling; whereas this is an example of information that describes the resource itself. That said, I'm not wed to the idea of a new header; Prefer: ttl=10 would work.

[martinthomson]

Discussed in Yokohama: we will leave this out of the core document; we will await a proposal that we can use as the basis for further discussion.

[brianraymor]

Priority is too overloaded a term, since it may refer to:

• Message Ordering
• Urgency ("Niceness") as in "Is it urgent enough to wake the device and burn the battery?"

Updating this issue to be specific to urgency. I plan to adapt and integrate Martin's Marking HTTP Requests as Unimportant as a proposed solution. For example:

• Nice 0 - send urgent message immediately and wake up the user agent
• Nice 1 - send opportunistically – send prior to expiration if no urgent messages are queued
• Nice 2 - send opportunistically – allow to expire if no urgent messages are queued

[beverloo]

We plan to include the Nice header in an upcoming version of our implementation with the following deliberate violation:

The "Nice" header field indicates that a request is less important than a request that doesn't bear this header.

Requests not bearing the Nice header will be treated as messages of default priority (similar to Nice: 1 in Brian's description).

The issue of defaulting to high priority is that the consequences of forgetting to include the header (waking up the UA) are disproportionate to the error - especially for more active users or users using a lower end device, this can have a very negative effect on the device's battery life.

There's definite value in allowing the push service to optimize for the default case. The application server can then supply the Nice header to clarify the intent and urgency of the message.

[martinthomson]

@beverloo, this is interesting. I'd like to reach some sort of consensus on how to present priority, especially defaults. Would recasting the header field into a three-valued enumeration of high/normal/low be a better fit for your use case? Webpush might interpret high as needing an urgent wakeup and low as being something that could wait until there were other messages to send.

At that point, we might as well call it Priority it's no longer really appropriate to call it Nice :( That suggests values of urgent, normal and non-urgent such as are used in the mail header field, which might be a better choice.

[jrconlin]

I have to admit, I have a few concerns about this proposal.

1. Priority - Push notifications are already pretty much temporal and priority, right? Essentially, this would offer a two state option of "Deliver this to my app NOW!" or "Deliver this whenever." My concern and complaint would be that the low priority messages probably shouldn't go through the web push channel. Instead, the app could spin up on it's own and check for outstanding messages that it might have, rather than use a complicated mechanism like push to do it.

2. Privacy - I like to think of the Push system as being like a mailman who's a jerk. A priority flag on a message would be delivered in the clear and would tell all the world, "Hey, if you're going to spend any time trying to break into a message, this would be a really good candidate." You could bury the flag inside the encrypted body, of course, but then you'd either have to make the UA far smarter about dealing with the body content of a push notification and that's probably not a great idea either.

3. Management - Doing distribution control on the server doesn't really make a lot of sense. For one, the connection between the server and the UA is always open, so the message should get distributed. This also means that if the UA is queuing these messages, it will have to determine when to toss messages when it runs low on resources, making low priority messages even more lossy. Plus, I'm willing to bet that apps will want to replace or recall low priority messages, meaning that there will eventually be some queue management system the UA will require, and I can see whatever battery savings that low priority messages might bring being eaten by the UA dealing with them.

tl;dr: have the app pull low priority messages when it likes. Push is a "high priority" system.

[beverloo]

I think both your messages present good arguments for reasoning about this as urgency rather than priority.

@martinthomson Having thought about this more, I do agree that Nice probably is not the best term. I certainly subscribe to Brian's mapping of the {0, 1, 2} values to their interpretation in context of Web Push, but those would work with {high, normal, low} urgency as well.

@jrconlin Let me reply to each of your points individually.

(1) An incoming phone call (real-time messaging) is more urgent than a received e-mail or social media invite, while you'd still like to know about the latter prior to the next use of your e-mail client. We'd like to avoid apps spinning up on their own to effectively poll for information, that could have a very negative impact on battery life.

(2) My goal is to avoid waking the UA up if there is no need to, so embedding this in the encrypted payload would not work. Does reasoning about this as urgency rather than priority help in regards to the attack vector? Several kinds of urgent messages tend to be more ephemeral as well.

(3) Distribution control on the server allows non-urgent message transmissions to be intelligently grouped together if the user isn't using their device, e.g. when they're asleep. This allows the open connection to remain in a lower activity state (e.g. PCH) for longer, using significantly less energy, while still allowing for the immediate delivery of urgent messages.

Furthermore, doing distribution control on your server allows the deletion and replacement of non-urgent messages to be done without informing the UA at all, for example following #9 for message collapsing.

[jrconlin]

I suppose I'm still not really seeing the value of this. As you note, a highly urgent message would require the UA to do work, the app to be woken and all the various things that should be required. It's a significant action. I'm not really sure I'd find it useful to be woken up at 3AM to be told that a server is down, oh, and that four of my old high school friends killed snakes in Farmville.

It may be that my server manages Farmville's virtual snake generation and both sets of information are equally useful, but probably not.

Messages are still noted as being "special" and therefore there's user meta data potentially being exposed, there's additional management and storage work that the server would need to do( particularly if a large partner were to start using this function) just to keep the app from doing a HTTP request.

I feel that we're adding a fair bit of complexity for little real gain. An app can still gather "low priority" messages from it's own server according to that app's specific logic. If there are additional complexities around those low priority messages, we can remain gleefully unaware of them and remain focused on ensuring that a message of import gets through our system as quickly and reliably as we can afford.

Of course, there's absolutely nothing preventing a push provider from offering this as a proprietary feature as well. I'd just rather this protocol not be made a magnificent hammer to use on every nail.

[jrconlin]

Having had a conversation with Ben about this, let me also clarify a few things.

1. An app could start for any reason. User activity, timer, etc. There is nothing preventing or discouraging that app from checking it's server for outstanding messages right now.

2. I understand the appeal of having extra information handed to an app that is being woken by a high priority message may bring. I feel that perhaps it would be better for app developers to understand that sending messages incurs a device cost. Instead of trying to fix the protocol (where only a small population may set a flag indicating "This message isn't urgent"), we instead make sure that app developers simply only send messages via our system that may cause folks to uninstall their app.

3. The idea of "low priority" messages bother me because any messages that are undelivered will bring complexity. If you have a message that reflects state (like 50 unread mail) do we deliver 50 messages? Perhaps it might make sense to consider "collapse" messages as low priority by default, as I believe you're suggesting, and deliver those to the UA only when a high priority "normal" notification is sent.

Sorry if I seem overly dense or antagonistic. I'll blame a head cold.

[bbangert]

@beverloo So far this only seems to cover the header sent to the Push Service, I assume there's some corresponding change to how a UA asks a Push Service for notifications such that it can do a one-off poll that indicates if there's any Nice 0 messages?

I'm somewhat concerned that Nice 2 messages increase database load for a Push Service, since accepting those notifications requires a database hit to see if they should even be stored.

Speaking of collapse keys, how do they go with urgency levels? Are topics unique to the urgency level? It would be weird for a Nice 0 message to replace a Nice 1 message with the same topic. I would expect topics with different urgency to be separate, or undefined improper behavior.

Edit: Not worried about the Nice 2 db read, since in cases there's no Nice 0 it'd avoid a db write which is generally more expensive than a read anyways.

[martinthomson]

@jrconlin, Part of the efficiency advantage of a push service is its ability to coalesce multiple messages into a single message to a user agent. That means delaying some messages. Urgency indicators help the push service decide how much delay is acceptable. (And as @bbangert notes, if the user agent can indicate an urgency on its polling request, that might govern push service behaviour as well. For instance, a mobile device that is on battery power overnight might want the push service to treat "normal" requests as "non-urgent" for that period.)

@bbangert, for simplicity, I would expect that the urgency of an updated push message will simply update the urgency of the topic. If it was previously non-urgent and becomes urgent, then it should be delivered urgently. (I can't imagine the opposite happening very often, but there you are).

[bbangert]

@martinthomson my main thought was that it could cause some odd results, since if its a Nice 2 topic, and there were no Nice 0 stored, it wouldn't collapse but actually just delete the existing one. Why a topic would go from Nice 1 -> Nice 2, I don't know offhand but I guess someone could dream up a case for that.

[costinm]

The headers should provide enough information to enable the push service to optimize for network and battery usage.

"Urgent" is clear - deliver ASAP, no matter what. A push service may look for abuse of "urgent", and I don't think it should be default. If the device is offline: urgent may still be affected by expiration and collapse, but as soon as the device gets connected urgent will be delivered.

The main issue is what kind of optimizations we can do for the others - and how to provide the right information in the headers so it's clear for both sender and push service what actions can be taken if a message is not urgent.

One problem is how long can the push service delay a non-urgent message, if the device is connected.
Expiration is not a good indicator - for "mail messages waiting" you may want a large expiry ( 1 day ) but you want to limit the delay for 15 min. If user is connected, message will be delayed up to 15 min, if not - it'll still be held for 1 day, and collapsed with more recent messages.

If a device is 'charging' and on wifi ( desktop browser ) - the push service may choose to just send all messages immediately - there are costs for delaying the messages. The spec shouldn't require that "nice=2" messages will be delayed - the nice should be an indication that some delay is acceptable. It's up to the app to notify or not notify you in the middle of the night that you got some unimportant notification.

If the device is on battery - and maybe hasn't been used for some time ( for example screen off, didn't move) - it makes a lot of sense to delay all messages until device is active. Keep in mind that on some devices when this mode is detected, apps may also be restricted on what they can do with incoming messages for battery saving. And the device itself may have some update windows when it can process the messages. IMHO this is the most important use of Nice - saving user's battery and making sure the
apps can handle the messages.

TTL=0 ( or very short expiration ) is another factor - not clear how it should interact with niceness. The main use is to not save the storage costs, if device is not connected.

[bbangert]

The WebPush spec covers how the client asks for notifications. When we talk of how the Push server has urgency values attached to notifications, I assume this means by necessity we will be talking about how the Push server knows all these various things about the client to make these determinations?

@costinm Do you plan on introducing additional flags for the client when making a notification request that conveys all this additional knowledge (on wifi, 'charging', etc) to the Push service? Is it the right place for the Push service to choose how to optimize delivery, or should the client flag indicate what level of urgency it wants notifications for?

[costinm]

GCM uses a binary protocol for UA-push service, which already has the flags ( it wouldn't work
otherwise for the deep sleep for example ). I think common ones could be added to webpush
spec, but with lots of care - we don't want the UA to send notifications too often (for example
on state change).

A start would be to define a header for the 'monitor' request, with a list of flags, and
define common ones ( charging, network type ).

[brianraymor]

Noting earlier httpbis discussion on the use of Prefer instead of a custom header