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

[Magnus Westerlund <[e-mail]>]

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?

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?

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?

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

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?

Cheers

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