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

[Costin Manolache <[e-mail]>]

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

> Hi,
>
> This review is an early, i.e. pre IETF Last Call TSV-ART review. The
> TSV-ART reviews document that has potential transport implications or
> transport related subjects. Please treat it as an IETF Last call comment
> if you don't want to handled it during the AD review.
>
> Document: draft-ietf-webpush-protocol-09
> Title: Generic Event Delivery Using HTTP Push
> Reviewer: M. Westerlund
> Review Date: Sept 27, 2016
>
> Below are a number of comments based on my review. The one with
> transport related subject is the overload handling in comment 4.
>
> 1. Section 3:
>
> So the Security Considerations do require use of HTTP over TLS. However,
> I do wonder if there would be a point to move that requirement up into
> the relevant connection sections, like 3. Especially as when one reads
> the confidentiality requirement in Section 4 for the message one wonders
> a bit why it is not explicitly required in section 3.
>
>
> 2. Section 5.2:
>
> TTL = 1*DIGIT
>
> Shouldn't the upper range for allowed values be specified here. At least
> to ensure that one doesn't get interoperability issues.
>
> 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?
>

I agree it needs more clarifications - expiring prior to TTL is the same
with
reducing the TTL, so at least that part seems redundant.

In GCM, this would happen only if the sender has too many messages for
a device. I assume some implementation of push may not want to load
the list of saved messages or counters before saving - there are replication
delays and cost savings - so it might make sense to let the pushservice drop
messages without telling the app server. In GCM there is a special message
that is sent to the UA if the pushservice dropped (collapsed) messages, so
UA can do a full sync.



>
> 4. Dealing with overload situations
>
> 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? 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?
>

In most cases the UA to push service link is lightly used - payload size is
limited, as is number of messages per device ( in particular for mobile ).
Yes, I think the assumption is the push service will store - and keep
attempting
to deliver.

There was a separate thread on how to control the flow - since push
promise doesn't have a response - the focus was on delivery receipts, where
overload is far more likely. For UA, the message ack can control the flow.


>
> 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?
>

Yes, so far that's what GCM is doing. Expectation is that app server will
retry with
backoff.


>
> 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.
>

Yes, another problem is that a push service can be global, and overload can
happen
only on a shard ( i.e. affect groups of users - but not the entire service
) - in particular
in case of DOS, bugs or an app server running load tests on too few devices.


>
> 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.
> 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.
>

In general, subscriptions are expected to last for a longer interval to
reduce
load ( devices calling subscribe, then sending the subscriptions to app
servers,
who need to store it ). On the other side, it's common for devices or
browsers to
be reset (clear data,etc) or stop being used.

The fact a device connects is an important signal - it is reasonable to keep
a subscription active while device keeps connection, but expire it after a
certain
time ( and also clear up any stored messages ). Adding some
numbers would be good - but I don't know what would be reasonable, it's
a trade-off between storage on server and traffic/battery on device.


>
> 6. Unclarities which requests that require HTTP/2.
>
> The specification is explicit that some request can be performed over
> HTTP/1.x. However, it is not particular clear which requests that
> require HTTP/2. I assume all the GET requests that will hang to enable
> PUSH promises needs to be HTTP/2? Maybe this should be clarified?
>

+1

Costin


>
> Cheers
>
> Magnus Westerlund
>
> ----------------------------------------------------------------------
> Services, Media and Network features, Ericsson Research EAB/TXM
> ----------------------------------------------------------------------
> Ericsson AB                 | Phone  [phone]
> <+46%2010%20714%2082%2087>
> Färögatan 6                 | Mobile [phone]
> <+46%2073%20094%2090%2079>
> SE-164 80 Stockholm, Sweden | mailto: [e-mail]
> ----------------------------------------------------------------------
>
> _______________________________________________
> Webpush mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/webpush
>