Re: [Webpush] Early TSV-ART review of draft-ietf-webpush-protocol-09

[Brian Raymor <[e-mail]>]

Magnus - Thanks for the review. I'll have a pull request available tomorrow to address most of your feedback. In the interim, I've shared a few comments and clarifications below.

On September 27, 2016 3:28 AM, Magnus Westerlund <[e-mail]> wrote:

<snip>

> 3. Section 7.2:

>    To limit the number of stored push messages, the push service MAY
>    either expire messages prior to their advertised Time-To-Live or
>    reduce their advertised Time-To-Live.

> Do I understand this correctly, that theses options are push service 
> side actions that is not notified at that point to the application 
> server? Instead it will have to note that the message was early expired 
> if it subscribes to delivery receipts?

This text should be clarified. There are two cases. First, the push service can only reduce the requested TTL in its response to a request from an application server to deliver a push message:

https://tools.ietf.org/html/draft-ietf-webpush-protocol-10#section-5.2

   A push service MAY retain a push message for a shorter duration than
   requested.  It indicates this by returning a TTL header field in its
   response with the actual TTL.  This TTL value MUST be less than or
   equal to the value provided by the application server.

Second, if an application server subscribes to delivery receipts it will receive a 410 if the push service does not then honor that TTL:

https://tools.ietf.org/html/draft-ietf-webpush-protocol-10#section-6.2

   The push service MAY cease to retry delivery of the message prior to
   its advertised expiration due to scenarios such as an unresponsive
   user agent or operational constraints.  If the application has
   requested a delivery receipt, then the push service MUST return a 410
   (Gone) response to the application server monitoring the receipt
   subscription.

If the application server does not subscribe to delivery receipts, then it's a fire-and-forget scenario.

> 4. Dealing with overload situations

Could webpush implementers review Magnus's questions below and consider whether there is further general guidance that can be offered based on their early experiences with the protocol?

> Reviewing Section 7.1 and other parts I find the discussion of how 
> overload situations of various kinds are dealt with missing some cases. 
> So the general handling of subscriptions are covered in Section 7.1 and 
> with a mitigation of redirecting to another server to handle the new 
> subscription.

> What I lack discussion of are how any form of push back are handled when 
> first the deliver of push service to UA link is overloaded. Is the 
> assumption here that as the push service can store messages the delivery 
> will catch up eventually, or the message expires? 

Your assumption in this case is basically correct. The push service could also use the acknowledgements from the user agent as an indicator of overload and reduce the rate.

> How does one handle a 
> 0-RTT messages when one has a queue of messages to deliver, despite 
> having a UA to Push service connection?

> The second case is how the push service server can push back on 
> accepting new message when it is overloaded. To me it appears that the 
> load on a push service can be very dynamic. Thus overload can really be 
> periods. Thus, what push back to application servers is intended here? 
> Just, do a 503 response on the request from the application server?

We decided on a 429. See https://www.ietf.org/mail-archive/web/webpush/current/msg00341.html - although it's also possible for the push service to terminate a subscription. 

https://tools.ietf.org/html/draft-ietf-webpush-protocol-10#section-8.4

   A push service MAY return a 429 (Too Many Requests) status code
   [RFC6585] when an application server has exceeded its rate limit for
   push message delivery to a push resource.  The push service SHOULD
   also include a Retry-After header [RFC7231] to indicate how long the
   application server is requested to wait before it makes another
   request to the push resource.

   A push service or user agent MAY also terminate subscriptions
   (Section 7.3) that receive too many push messages.

> I do note that RFC 7231 does not appear to have any guidance one how one 
> sets the Retry-After header to spread the load of the retries. This is a 
> known issue. And in this context with automated or external event 
> triggered message creations the push back mechanism needs to be robust 
> and reduce the issues, not make them worse.

> I would recommend that some recommendations are actually included here 
> for handling overload from application server message submissions.

> 5. Life of subscription in relation to transports

> I find myself a bit perplexed of if there are any relation between the 
> subscription and the relation to an existing transport connection and 
> outstanding request, i.e. the availability to receive messages over 
> push. I would guess, that there are no strict need for terminating the 
> subscription even if there are no receiver for an extended time. 

Especially for mobile and/or battery powered clients, the expectation is that
the user agents will be dormant for extended periods of time.

> However, from an application perspective there could exists reason for 
> why a subscription would not be terminated as long as the UA is 
> connected, while any longer duration of no connections could motivate 
> the subscription termination.

> I personally would like a bit more clarification on this, but seeing how 
> these issues are usually handled around HTTP, I would guess the answer, 
> it will be implementation specific? Still there appear to be assumptions 
> around this, why it wouldn't matter that much, but that is only given 
> that one follows these assumptions.

I think that your assumption is correct. The behavior is specific to the push service.
Implementers have requested the ability for a push service to terminate a subscription
at will based on its internal policies.

Again, I'd ask that the webpush implementers share any general guidance or observations for this case.

<snip>