Re: [Webpush] Early TSV-ART review of draft-ietf-webpush-protocol-09
Alissa Cooper <alissa@cooperw.in> Mon, 10 October 2016 13:21 UTC
Return-Path: <alissa@cooperw.in>
X-Original-To: webpush@ietfa.amsl.com
Delivered-To: webpush@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5D161296A4; Mon, 10 Oct 2016 06:21:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cooperw.in header.b=dbVZjdGb; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=AA8RlrN3
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hkESesb213xG; Mon, 10 Oct 2016 06:21:51 -0700 (PDT)
Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43C001296A8; Mon, 10 Oct 2016 06:21:51 -0700 (PDT)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id ACEF1206A4; Mon, 10 Oct 2016 09:21:50 -0400 (EDT)
Received: from frontend2 ([10.202.2.161]) by compute3.internal (MEProxy); Mon, 10 Oct 2016 09:21:50 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=ophTu272kjJcH//+0+s5YlKuWQE=; b=dbVZjd GbcqkO1uiHKZk39/e5hqjuJ8UE0kkWfHS0LA0uWtsrJntc6+bUO6zxAREWfmA9/q STLTvjY3tQhUL7PlyJb/CNkW8se+8ek+N/PfwNXjxi8UkAiyGKFqhi8BzFQ9jSln 8BbD/3cFNERp8LUc0VRz2gNJAKTjOydrD6Hz4=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=ophTu272kjJcH// +0+s5YlKuWQE=; b=AA8RlrN3f7Z/pf2uSAdgm7lWUF9zS8OSKOcAYcATLN1tiDo HfgG2lvCvDqr/T+Bj6wl45J3n5f8TIrC5QLEnQjti1YbMUGrqkA1uqk4YH4g/llV axgOYWT5wSgK/tEVmDKpXDOqlkoKHo4fSscwGSQkxtKWhqMUCGYkm36MPm24=
X-Sasl-enc: T/WYH4J6Ob7rZ3t13ePzzcgOwzDhIjZ9R3VZpG/qNik7 1476105710
Received: from dhcp-10-150-9-141.cisco.com (unknown [173.38.117.65]) by mail.messagingengine.com (Postfix) with ESMTPA id 57EC4CC07D; Mon, 10 Oct 2016 09:21:50 -0400 (EDT)
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Alissa Cooper <alissa@cooperw.in>
In-Reply-To: <4baa72c6-cd52-19d5-c070-4a19336c23ed@ericsson.com>
Date: Mon, 10 Oct 2016 09:21:51 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <08A740FC-B283-404D-AF3C-E97D574E9642@cooperw.in>
References: <1f645188-2344-ebf3-1228-3735bcf81338@ericsson.com> <CY1PR03MB23800B9F4C7BEF6137E5EEA483C50@CY1PR03MB2380.namprd03.prod.outlook.com> <CY1PR03MB238084C15B9BEEBE0F8CD8C683C40@CY1PR03MB2380.namprd03.prod.outlook.com> <4baa72c6-cd52-19d5-c070-4a19336c23ed@ericsson.com>
To: "draft-ietf-webpush-protocol@ietf.org" <draft-ietf-webpush-protocol@ietf.org>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/webpush/p79BjqKOeHN4tnb-hpO4dEoHaro>
Cc: "webpush@ietf.org" <webpush@ietf.org>
Subject: Re: [Webpush] Early TSV-ART review of draft-ietf-webpush-protocol-09
X-BeenThere: webpush@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Discussion of potential IETF work on a web push protocol <webpush.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/webpush>, <mailto:webpush-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/webpush/>
List-Post: <mailto:webpush@ietf.org>
List-Help: <mailto:webpush-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/webpush>, <mailto:webpush-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 10 Oct 2016 13:21:54 -0000
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 <magnus.westerlund@ericsson.com> 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:Brian.Raymor@microsoft.com] Sent: Monday, October 3, 2016 >> 7:33 PM To: Magnus Westerlund <magnus.westerlund@ericsson.com>; >> tsv-art@ietf.org; draft-ietf-webpush-protocol@ietf.org; >> webpush@ietf.org; webpush-ads@ietf.org 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 >> <magnus.westerlund@ericsson.com> 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 +46 10 7148287 > Färögatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >
- [Webpush] Early TSV-ART review of draft-ietf-webp… Magnus Westerlund
- Re: [Webpush] Early TSV-ART review of draft-ietf-… Brian Raymor
- Re: [Webpush] Early TSV-ART review of draft-ietf-… Costin Manolache
- Re: [Webpush] Early TSV-ART review of draft-ietf-… Brian Raymor
- Re: [Webpush] Early TSV-ART review of draft-ietf-… Magnus Westerlund
- Re: [Webpush] Early TSV-ART review of draft-ietf-… Alissa Cooper
- Re: [Webpush] Early TSV-ART review of draft-ietf-… Brian Raymor