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

[Brian Raymor <[e-mail]>]

webpush-11 was published. 

At this time, no further clarifications were added for #4.

-----Original Message-----
From: Alissa Cooper [mailto:[e-mail]] 
Sent: Monday, October 10, 2016 6:22 AM
To: [e-mail]
Cc: [e-mail]
Subject: Re: Early TSV-ART review of draft-ietf-webpush-protocol-09

The IESG will be reviewing this draft this week as it is scheduled for the telechat on Thursday, so please post the -11 version as soon as possible (including any text needed to address #4 below).

Thanks,
Alissa

> On Oct 5, 2016, at 9:08 AM, Magnus Westerlund <[e-mail]> wrote:
> 
> Hi,
> 
> I have looked at the pull request which looks good, with one very minor comment that you should check out on github.
> 
> Cheers
> 
> Magnus
> 
> 
> Den 2016-10-05 kl. 05:10, skrev Brian Raymor:
>> I've created an initial pull request for review -
>> https://github.com/webpush-wg/webpush-protocol/pull/131 - while we
>> discuss whether there's additional guidance that can be shared for
>> "4. Dealing with overload situations".
> 
> 
> 
>> 
>> 
>> -----Original Message----- From: Brian Raymor
>> [mailto:[e-mail]] Sent: Monday, October 3, 2016
>> 7:33 PM To: Magnus Westerlund <[e-mail]>om>;
>> [e-mail]; [e-mail];
>> [e-mail]; [e-mail] Subject: RE: Early TSV-ART
>> review of draft-ietf-webpush-protocol-09
>> 
>> 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>
>> 
>> 
>> 
> 
> 
> -- 
> 
> Magnus Westerlund
> 
> ----------------------------------------------------------------------
> Services, Media and Network features, Ericsson Research EAB/TXM
> ----------------------------------------------------------------------
> Ericsson AB                 | Phone  [phone]
> Färögatan 6                 | Mobile [phone]
> SE-164 80 Stockholm, Sweden | mailto: [e-mail]
> ----------------------------------------------------------------------
>