From nobody Mon Oct 3 19:33:20 2016 Return-Path: X-Original-To: tsv-art@ietfa.amsl.com Delivered-To: tsv-art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E1A6129579; Mon, 3 Oct 2016 19:33:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 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_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com 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 Gx0Ntkw-TB6l; Mon, 3 Oct 2016 19:33:15 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0139.outbound.protection.outlook.com [104.47.40.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8302B1295AC; Mon, 3 Oct 2016 19:33:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=xsUkgcal8vN+OgtHwQDzNZSoOkHKTVp0BjZfLkbUcNg=; b=GkjiE/4MRBusk57RkqqII7aF0P1W2fpi9wTsrKH5Q/Ozvktuc2jFKpf1ts6I/oCwgvFQ8Mu6IW9T5xjkdhtppRUi/y8ZNPxgxo0BzmQaqxnnJNOIjQz0W0E6Jp9sWdxh9NmZFCraDI8Uemu0is1xb0GIOPjROSxvOVIlCCoF6UI= Received: from CY1PR03MB2380.namprd03.prod.outlook.com (10.167.8.6) by CY1PR03MB2380.namprd03.prod.outlook.com (10.167.8.6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.639.5; Tue, 4 Oct 2016 02:33:14 +0000 Received: from CY1PR03MB2380.namprd03.prod.outlook.com ([10.167.8.6]) by CY1PR03MB2380.namprd03.prod.outlook.com ([10.167.8.6]) with mapi id 15.01.0639.015; Tue, 4 Oct 2016 02:33:13 +0000 From: Brian Raymor To: Magnus Westerlund , "tsv-art@ietf.org" , "draft-ietf-webpush-protocol@ietf.org" , "webpush@ietf.org" , "webpush-ads@ietf.org" Thread-Topic: Early TSV-ART review of draft-ietf-webpush-protocol-09 Thread-Index: AQHSGKne4rZHBz7KIU6jZUnx6IKSHaCXcP9w Date: Tue, 4 Oct 2016 02:33:13 +0000 Message-ID: References: <1f645188-2344-ebf3-1228-3735bcf81338@ericsson.com> In-Reply-To: <1f645188-2344-ebf3-1228-3735bcf81338@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Brian.Raymor@microsoft.com; x-originating-ip: [174.61.159.182] x-ms-office365-filtering-correlation-id: 99a905da-651f-4cc2-2c96-08d3ebfeca71 x-microsoft-exchange-diagnostics: 1; CY1PR03MB2380; 6:EnBoUNJnNf15yjQpxxhaTk0+QHPdchO18F1znAMaLOOELMdllM/AVVKbc6qnJZmDo0FNexbmKyeJP7izsARMpX+yhqaD0xAjPxmvL9gXA2XDMeXkCxZDgUz1EToujUGCfeRZ0sorYSPQfO5RDFWhx6wZ4zFxgwek/7bAMZJpDDrojBCDnDgXjWusknrBqDJRfZ8PlpUu8Ek91u0GAgaAaFAPxXB+bwTC/yuiKSnvZFLECwfrZMaCg6U5psNXh0uNS03OP65Rpnymy2+jkM1vKV00xqdcAmMT/poRvmB2s2ImEr/eW7VSZ6LK19tkWD8dyj4JU5PTzLsD1M99e7mIQQ==; 5:xjnzXBcaBZwLmsCLQwlBgqOUbYaFhWDuAIYfWXvu5Pi5UT9z+lJ34RYHv0a68LBcwASteE1fTRkjbpF4KfRe/URKYmx++0IANFPhzA+Cf5LHBTBy/mGLJNnFd3ozBFOBenjHXjsUfGV7vUvydCttew==; 24:icuw+543/6BGl4VFgkCWXMf9GQZzMWv/PVPps0MA0cA9c0SWlAekTH+ITwMHTBBF08HCv7CMYcyhMl1XopOcEtXb6vcT/jh8xOK5P/GZeDw=; 7:XdJkwp0Y1J5uIBRk5Lx7TLwoz17ehrKrkTvz3cne2hZe3cHvjGplI2gQU1wRNcL/rjojR9l+L/3R4wJtK0nXkvqfp6a6+JG4jNOVP54u59OcabgAAlYnYerwJOHC0372jle5gstT7wtCmM7FYr15pacuigXnLqq7HmEcwnYX+ROuTZAChDx1bBKOH2nnvMHowiCe15rDujsBz5oIVUrJ/GrdlIiT04muzXdFhtnm0oO7+f25QDZctnL/wQWDMnFw5MFHITQY6If3db7Yhp1okiU6oIAljk6PD3OteVinVg/Ywf7714dbOEFX5R1mLJyq x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR03MB2380; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(158342451672863)(72170088055959); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:CY1PR03MB2380; BCL:0; PCL:0; RULEID:; SRVR:CY1PR03MB2380; x-forefront-prvs: 00851CA28B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(189002)(51914003)(24454002)(51444003)(199003)(377454003)(68736007)(6116002)(50986999)(54356999)(8936002)(77096005)(5005710100001)(106116001)(7846002)(10090500001)(92566002)(76176999)(107886002)(2950100002)(10400500002)(2900100001)(8990500004)(9686002)(66066001)(10290500002)(189998001)(5002640100001)(76576001)(2501003)(97736004)(15975445007)(102836003)(2906002)(5001770100001)(3846002)(74316002)(122556002)(87936001)(8676002)(7696004)(86362001)(19580395003)(33656002)(3660700001)(106356001)(105586002)(99286002)(5660300001)(3280700002)(86612001)(7736002)(81166006)(101416001)(305945005)(586003)(2201001)(81156014)(230783001)(19580405001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR03MB2380; H:CY1PR03MB2380.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Oct 2016 02:33:13.6764 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR03MB2380 Archived-At: Subject: Re: [Tsv-art] Early TSV-ART review of draft-ietf-webpush-protocol-09 X-BeenThere: tsv-art@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Review Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2016 02:33:18 -0000 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 commen= ts and clarifications below. On September 27, 2016 3:28 AM, Magnus Westerlund wrote: > 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=20 > side actions that is not notified at that point to the application=20 > server? Instead it will have to note that the message was early expired=20 > 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 app= lication 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 re= ceive 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 whe= ther there is further general guidance that can be offered based on their e= arly experiences with the protocol? > Reviewing Section 7.1 and other parts I find the discussion of how=20 > overload situations of various kinds are dealt with missing some cases.=20 > So the general handling of subscriptions are covered in Section 7.1 and=20 > with a mitigation of redirecting to another server to handle the new=20 > subscription. > What I lack discussion of are how any form of push back are handled when= =20 > first the deliver of push service to UA link is overloaded. Is the=20 > assumption here that as the push service can store messages the delivery= =20 > will catch up eventually, or the message expires?=20 Your assumption in this case is basically correct. The push service could a= lso use the acknowledgements from the user agent as an indicator of overloa= d and reduce the rate. > How does one handle a=20 > 0-RTT messages when one has a queue of messages to deliver, despite=20 > having a UA to Push service connection? > The second case is how the push service server can push back on=20 > accepting new message when it is overloaded. To me it appears that the=20 > load on a push service can be very dynamic. Thus overload can really be=20 > periods. Thus, what push back to application servers is intended here?=20 > 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/curr= ent/msg00341.html - although it's also possible for the push service to ter= minate a subscription.=20 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= =20 > sets the Retry-After header to spread the load of the retries. This is a= =20 > known issue. And in this context with automated or external event=20 > triggered message creations the push back mechanism needs to be robust=20 > and reduce the issues, not make them worse. > I would recommend that some recommendations are actually included here=20 > 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=20 > subscription and the relation to an existing transport connection and=20 > outstanding request, i.e. the availability to receive messages over=20 > push. I would guess, that there are no strict need for terminating the=20 > subscription even if there are no receiver for an extended time.=20 Especially for mobile and/or battery powered clients, the expectation is th= at the user agents will be dormant for extended periods of time. > However, from an application perspective there could exists reason for=20 > why a subscription would not be terminated as long as the UA is=20 > connected, while any longer duration of no connections could motivate=20 > the subscription termination. > I personally would like a bit more clarification on this, but seeing how= =20 > these issues are usually handled around HTTP, I would guess the answer,=20 > it will be implementation specific? Still there appear to be assumptions= =20 > around this, why it wouldn't matter that much, but that is only given=20 > that one follows these assumptions. I think that your assumption is correct. The behavior is specific to the pu= sh service. Implementers have requested the ability for a push service to terminate a s= ubscription at will based on its internal policies. Again, I'd ask that the webpush implementers share any general guidance or = observations for this case. From nobody Tue Oct 4 18:58:29 2016 Return-Path: X-Original-To: tsv-art@ietfa.amsl.com Delivered-To: tsv-art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE056129447; Tue, 4 Oct 2016 18:58:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 o2itJ1WvOZwI; Tue, 4 Oct 2016 18:58:25 -0700 (PDT) Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 142A7128E18; Tue, 4 Oct 2016 18:58:25 -0700 (PDT) Received: by mail-pa0-x235.google.com with SMTP id ik13so25602854pac.2; Tue, 04 Oct 2016 18:58:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=B1GHlHdxzShChmWNkWK5wK/wrQS7K71KyxWSNoNbyCw=; b=SPk5Hj6aHBHxmrkJFtnj4PGGDtiCaBk22hGAPHbj33IxCL141L7z9vuOAfRzZz2DE2 Bj7wv+DOWd7Yf3R6EsfT9/NIrSoBvKuDRuXJA2pppEaAWNWTmHojxr9Xlczerw+HGcir QTdRgz3AM7YBkbAddsc6I95/g1k06OHQkkL+zH4YKaC9+Wx1ahz9/IjrIMm8OHNyhfD7 I/bnD1k5LVo5yFIgRGaljxXofMC4kawzl5Rjc8Y6qcJOC6/HsV5MnCht5TWdRnM6CwoE J9yRIsiZC59n40SNpIvcIPUjnaD/cDJPmVB7PkNxweEQNJbftR2MdlM0J8QeuxwB6rno pWKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=B1GHlHdxzShChmWNkWK5wK/wrQS7K71KyxWSNoNbyCw=; b=Hvo7pNMdpj/dKzarKeD4aAtyQG1I6VfrZAKlMW3uXABjyAw+cdMhjh9KcqnkkJZmQ8 TAQz0rC4fPojwxzF1Shmn96lHaKQNzxKFA89iGecW1I0nk2WVV77faD60yiru8wv1Z35 BUwz0kMngsgNseNhA46M9KmP9pLUlkKw1wm3sALB7Nr5pv6i6QyICX1UpQtB2illBKtS cTUS9T7bgoxRxMeFgVjSWuGRpcwQmtt9jbaF027ROuESz8sJprOhpIuZ/26J3oLoymhX StUiCFRJl6x9Zoy/AhOFNKI+//MN3FhvUatHk3hbTOGFouWri6byx3j71DVbudBnCA8S Dttw== X-Gm-Message-State: AA6/9Rn5Og57KXupyY0T4UFMMHDSTV3HdxoPF37jeVrlu0AglBeUcM3R7Ag56L7M/Z4fQvINNkU7Kjhr0hXU3A== X-Received: by 10.66.237.133 with SMTP id vc5mr9560902pac.24.1475632704626; Tue, 04 Oct 2016 18:58:24 -0700 (PDT) MIME-Version: 1.0 References: <1f645188-2344-ebf3-1228-3735bcf81338@ericsson.com> In-Reply-To: <1f645188-2344-ebf3-1228-3735bcf81338@ericsson.com> From: Costin Manolache Date: Wed, 05 Oct 2016 01:58:13 +0000 Message-ID: To: Magnus Westerlund , tsv-art@ietf.org, draft-ietf-webpush-protocol@ietf.org, webpush@ietf.org, webpush-ads@ietf.org Content-Type: multipart/alternative; boundary=047d7b15fd972da7ad053e148393 Archived-At: Subject: Re: [Tsv-art] [Webpush] Early TSV-ART review of draft-ietf-webpush-protocol-09 X-BeenThere: tsv-art@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Review Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2016 01:58:28 -0000 --047d7b15fd972da7ad053e148393 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Sep 27, 2016 at 3:28 AM Magnus Westerlund < magnus.westerlund@ericsson.com> 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 =3D 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 replicatio= n delays and cost savings - so it might make sense to let the pushservice dro= p 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 kee= p 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 +46 10 7148287 > <+46%2010%20714%2082%2087> > F=C3=A4r=C3=B6gatan 6 | Mobile +46 73 0949079 > <+46%2073%20094%2090%2079> > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush > --047d7b15fd972da7ad053e148393 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue= , Sep 27, 2016 at 3:28 AM Magnus Westerlund <magnus.westerlund@ericsson.com> 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 =3D 1*DIGIT

Shouldn't the upper range for allowed values be specified here. At leas= t
to ensure that one doesn't get interoperability issues.

3. Section 7.2:

=C2=A0 =C2=A0 To limit the number of stored push messages, the push service= MAY
=C2=A0 =C2=A0 either expire messages prior to their advertised Time-To-Live= or
=C2=A0 =C2=A0 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 t= o TTL is the same with=C2=A0
reducing the TTL, so at least that p= art seems redundant.=C2=A0

In GCM, this would happ= en only if the sender has too many messages for
a device. I assum= e some implementation of push may not want to load
the list of sa= ved messages or counters before saving - there are replication
de= lays and cost savings - so it might make sense to let the pushservice drop<= /div>
messages without telling the app server. In GCM there is a specia= l message
that is sent to the UA if the pushservice dropped (coll= apsed) messages, so
UA can do a full sync.

=C2=A0

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 u= sed - payload size is=C2=A0
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 focu= s was on delivery receipts, where
overload is far more likely. Fo= r UA, the message ack can control the flow. =C2=A0
=C2=A0

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 wha= t GCM is doing. Expectation is that app server will retry with=C2=A0
<= div>backoff.
=C2=A0

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 gr= oups of users - but not the entire service ) - in particular
in c= ase of DOS, bugs or an app server running load tests on too few devices.
=C2=A0

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 longe= r interval to reduce
load ( devices calling subscribe, then sendi= ng the subscriptions to app servers,
who need to store it ). On t= he other side, it's common for devices or browsers to
be rese= t (clear data,etc) or stop being used.=C2=A0

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

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
=C2=A0

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| = Phone=C2=A0 +46 10 7148287
F=C3=A4r=C3=B6gatan 6=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0| Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericss= on.com
----------------------------------------------------------------------

_______________________________________________
Webpush mailing list
W= ebpush@ietf.org
https://www.ietf.org/mailman/listin= fo/webpush
--047d7b15fd972da7ad053e148393-- From nobody Tue Oct 4 20:10:29 2016 Return-Path: X-Original-To: tsv-art@ietfa.amsl.com Delivered-To: tsv-art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B17221293E0; Tue, 4 Oct 2016 20:10:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 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_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com 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 Dfs4UloAxRNM; Tue, 4 Oct 2016 20:10:24 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0099.outbound.protection.outlook.com [104.47.41.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A32F4128874; Tue, 4 Oct 2016 20:10:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=/6WKfhXpS1DupmZymnmc2Fw2A1i4LGcN2LSRe9TTo2s=; b=Nz1w/gjqqw381ppxaj4yV8xPz5EHOx4gsMsZpR6Yg4SwkMn5d3H++W7sEW4Fn5c0v/Ho3CTZ54vZjcYToecOya8P+TqtaBUEbBru/hDwyiiZKxHpKxSnhmCTAEnAarq9wp5qV93AXmuDu3CsB0qlVkkCxyACvKU/rE9orLcVa0s= Received: from CY1PR03MB2380.namprd03.prod.outlook.com (10.167.8.6) by CY1PR03MB2379.namprd03.prod.outlook.com (10.166.207.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.649.16; Wed, 5 Oct 2016 03:10:23 +0000 Received: from CY1PR03MB2380.namprd03.prod.outlook.com ([10.167.8.6]) by CY1PR03MB2380.namprd03.prod.outlook.com ([10.167.8.6]) with mapi id 15.01.0639.017; Wed, 5 Oct 2016 03:10:23 +0000 From: Brian Raymor To: Magnus Westerlund , "tsv-art@ietf.org" , "draft-ietf-webpush-protocol@ietf.org" , "webpush@ietf.org" , "webpush-ads@ietf.org" Thread-Topic: Early TSV-ART review of draft-ietf-webpush-protocol-09 Thread-Index: AQHSGKne4rZHBz7KIU6jZUnx6IKSHaCXcP9wgAHHqeA= Date: Wed, 5 Oct 2016 03:10:23 +0000 Message-ID: References: <1f645188-2344-ebf3-1228-3735bcf81338@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Brian.Raymor@microsoft.com; x-originating-ip: [174.61.159.182] x-ms-office365-filtering-correlation-id: fef188a6-6d03-45b8-56d8-08d3eccd259a x-microsoft-exchange-diagnostics: 1; CY1PR03MB2379; 7:6MWkfBGbP9Lst38Sk3qkmVFqQxiQf+VaaksJVloiDLwfxv40YyXyFZOj0yXvYpirHlDtw35MHuVW6R8//MAmCZXYiF8ANhiqo5tckncz6tx3I6LKIeFSxjksNpLeiuMYs+h2cB/KxHGnlCjTT4nZpQ1/0G82zo5YrGH0DcRjZNW6seV/vA2BixfRcOLZu/N/Xbg6YGuCqgPwFU1Ff9RVY++y96dbj/5ym+VZ6HYtRQ6rqGJjj4J/fOgzF/Q2tWJJKnQQW/IQkFVYAR781J1wQ3DLIO5Xu3s83a8FcitpLJYPEJIC/2+iHhqAjCSgqzyeJg/Q9uqlkM9AUaucaS6dyQ== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR03MB2379; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(158342451672863)(72170088055959)(166708455590820); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:CY1PR03MB2379; BCL:0; PCL:0; RULEID:; SRVR:CY1PR03MB2379; x-forefront-prvs: 008663486A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(377454003)(24454002)(189002)(51444003)(13464003)(199003)(51914003)(5002640100001)(105586002)(54356999)(2900100001)(3660700001)(76176999)(3280700002)(106116001)(107886002)(189998001)(15975445007)(86362001)(230783001)(81166006)(8676002)(76576001)(8936002)(106356001)(8990500004)(99286002)(87936001)(77096005)(7696004)(10290500002)(5005710100001)(2201001)(81156014)(10400500002)(2501003)(66066001)(7846002)(586003)(7736002)(122556002)(92566002)(2906002)(101416001)(86612001)(68736007)(6116002)(3846002)(11100500001)(102836003)(305945005)(97736004)(74316002)(33656002)(5001770100001)(5660300001)(50986999)(19580405001)(10090500001)(9686002)(2950100002)(19580395003); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR03MB2379; H:CY1PR03MB2380.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Oct 2016 03:10:23.1343 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR03MB2379 Archived-At: Subject: Re: [Tsv-art] Early TSV-ART review of draft-ietf-webpush-protocol-09 X-BeenThere: tsv-art@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Review Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2016 03:10:28 -0000 I've created an initial pull request for review - https://github.com/webpus= h-wg/webpush-protocol/pull/131 - while we discuss whether there's additiona= l guidance that can be shared for "4. Dealing with overload situations". -----Original Message----- From: Brian Raymor [mailto:Brian.Raymor@microsoft.com]=20 Sent: Monday, October 3, 2016 7:33 PM To: Magnus Westerlund ; tsv-art@ietf.org; d= raft-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 commen= ts and clarifications below. On September 27, 2016 3:28 AM, Magnus Westerlund wrote: > 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=20 > side actions that is not notified at that point to the application=20 > server? Instead it will have to note that the message was early expired=20 > 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 app= lication 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 re= ceive 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 whe= ther there is further general guidance that can be offered based on their e= arly experiences with the protocol? > Reviewing Section 7.1 and other parts I find the discussion of how=20 > overload situations of various kinds are dealt with missing some cases.=20 > So the general handling of subscriptions are covered in Section 7.1 and=20 > with a mitigation of redirecting to another server to handle the new=20 > subscription. > What I lack discussion of are how any form of push back are handled when= =20 > first the deliver of push service to UA link is overloaded. Is the=20 > assumption here that as the push service can store messages the delivery= =20 > will catch up eventually, or the message expires?=20 Your assumption in this case is basically correct. The push service could a= lso use the acknowledgements from the user agent as an indicator of overloa= d and reduce the rate. > How does one handle a=20 > 0-RTT messages when one has a queue of messages to deliver, despite=20 > having a UA to Push service connection? > The second case is how the push service server can push back on=20 > accepting new message when it is overloaded. To me it appears that the=20 > load on a push service can be very dynamic. Thus overload can really be=20 > periods. Thus, what push back to application servers is intended here?=20 > 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/curr= ent/msg00341.html - although it's also possible for the push service to ter= minate a subscription.=20 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= =20 > sets the Retry-After header to spread the load of the retries. This is a= =20 > known issue. And in this context with automated or external event=20 > triggered message creations the push back mechanism needs to be robust=20 > and reduce the issues, not make them worse. > I would recommend that some recommendations are actually included here=20 > 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=20 > subscription and the relation to an existing transport connection and=20 > outstanding request, i.e. the availability to receive messages over=20 > push. I would guess, that there are no strict need for terminating the=20 > subscription even if there are no receiver for an extended time.=20 Especially for mobile and/or battery powered clients, the expectation is th= at the user agents will be dormant for extended periods of time. > However, from an application perspective there could exists reason for=20 > why a subscription would not be terminated as long as the UA is=20 > connected, while any longer duration of no connections could motivate=20 > the subscription termination. > I personally would like a bit more clarification on this, but seeing how= =20 > these issues are usually handled around HTTP, I would guess the answer,=20 > it will be implementation specific? Still there appear to be assumptions= =20 > around this, why it wouldn't matter that much, but that is only given=20 > that one follows these assumptions. I think that your assumption is correct. The behavior is specific to the pu= sh service. Implementers have requested the ability for a push service to terminate a s= ubscription at will based on its internal policies. Again, I'd ask that the webpush implementers share any general guidance or = observations for this case. From nobody Wed Oct 5 06:08:34 2016 Return-Path: X-Original-To: tsv-art@ietfa.amsl.com Delivered-To: tsv-art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84FC21296F3; Wed, 5 Oct 2016 06:08:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 IySXUeH31mb7; Wed, 5 Oct 2016 06:08:27 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A73B1296EA; Wed, 5 Oct 2016 06:08:26 -0700 (PDT) X-AuditID: c1b4fb2d-5b107980000009f7-aa-57f4fb491bb8 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.183.84]) by (Symantec Mail Security) with SMTP id 45.E1.02551.94BF4F75; Wed, 5 Oct 2016 15:08:25 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.86) with Microsoft SMTP Server id 14.3.301.0; Wed, 5 Oct 2016 15:08:23 +0200 To: Brian Raymor , "tsv-art@ietf.org" , "draft-ietf-webpush-protocol@ietf.org" , "webpush@ietf.org" , "webpush-ads@ietf.org" References: <1f645188-2344-ebf3-1228-3735bcf81338@ericsson.com> From: Magnus Westerlund Message-ID: <4baa72c6-cd52-19d5-c070-4a19336c23ed@ericsson.com> Date: Wed, 5 Oct 2016 15:08:21 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrKLMWRmVeSWpSXmKPExsUyM2J7iK7n7y/hBq/fSFncn/eIyWLx9wY2 i1l7FrFYtF86w25x5fRfdgdWjyVLfjJ5tO74yx7AFMVlk5Kak1mWWqRvl8CVsfrWEraCaTYV c+b+ZmpgfG7QxcjJISFgInHgzAX2LkYuDiGB9YwS3S2bGEESQgLLGCXenrQCsYUFnCVWXjnL DFIkIvCfUeL8/80sEEVPGSWunuYCsdkELCRu/mhkA7F5BewlOjq2soPYLAIqElO23WYCsUUF YiSuP3sEVSMocXLmE6A5HBycArESjZsiQUxmoNYHW8tAKpgF5CWat85mhtikLdHQ1ME6gZF/ FpLmWQgds5B0LGBkXsUoWpxaXJybbmSsl1qUmVxcnJ+nl5dasokRGJgHt/zW3cG4+rXjIUYB DkYlHt4HWz+HC7EmlhVX5h5ilOBgVhLh1fz1JVyINyWxsiq1KD++qDQntfgQozQHi5I4r9nK ++FCAumJJanZqakFqUUwWSYOTqkGRgV/lRfJrRHXtj6+81lfpyZyQsjNmiebljSetrL+4xxz 9/56G+MNpvF1Ocfd7vmvm1KvZ6G+6YXU3MwPXELm5w/YvvuoJXH/jsekAqPC8HClXVnWRurf avwTF/A4dE/Nqvm37c73LS1W7Ud0trHou2oLJE1akvRzpUZ+jLGMG//v0gSR9a1BSizFGYmG WsxFxYkAAh7BnUgCAAA= Archived-At: Subject: Re: [Tsv-art] Early TSV-ART review of draft-ietf-webpush-protocol-09 X-BeenThere: tsv-art@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Review Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2016 13:08:32 -0000 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 ; > 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 > wrote: > > > >> 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. > > > > > -- 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 ---------------------------------------------------------------------- From nobody Mon Oct 10 09:02:08 2016 Return-Path: X-Original-To: tsv-art@ietfa.amsl.com Delivered-To: tsv-art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 017D6129459; Mon, 10 Oct 2016 09:02:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 lshxfEQuHcBK; Mon, 10 Oct 2016 09:02:04 -0700 (PDT) Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9BD9129488; Mon, 10 Oct 2016 09:02:04 -0700 (PDT) Received: by mail-yw0-x235.google.com with SMTP id t193so74602519ywc.2; Mon, 10 Oct 2016 09:02:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc; bh=LHXkqGufPKS+ytoAwjHBcjBrfb9jXUGttF3/BP50r1A=; b=YwKPcNKkpBMtN9wL5D3+2cE2SfTzH63vDfzMgHqssgO4ttLNY5au74GHh6ZtHAx9sN eKhdJNBuWEbL5335aWqDy+IWNZge2DMXoDpAxTzwt1QYU4+xj2KsHnRWM3upxSBxktKp gGg2zUg7walZC9AXcCkXW5K1OS1q4LitStg0F4SV4myv5F6gfqfqA/IUBgRLu0+XNVXz CF3P1GOPR3faqQ67Q8wgYQ38YkAXTf5NFi1bIeItc2H61Xat2Ul/kA84NFSt/0noFVqV H/+7/pOp66bYKgx1jccdPd5ST4/ryo1EvA3jHbvOdwCwY0FQ/7nOGPDT8z1s7M6OSOMT s+JA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=LHXkqGufPKS+ytoAwjHBcjBrfb9jXUGttF3/BP50r1A=; b=fbbNHhXCiB19axAoHEaiSGwrMY8rl6RBzorNkPqzcct88YzXJ0CHCyETFy92soCPL1 fzhtF9CtkAu+ZAw9f8fg+tbuQIi8GxBUgpdcSpeHj3+jhpiBCtitGLdmkgz5M35xdNcG h3Vj7Mk4J2GgFSsjeTHZSLgM+5jbFfJNzbZcpgsRRcH9GttiH9KyDI6Dh5vL8JqJeMDl I204/UxU+H6FEG2Y99m9L9gX/EjEC2UhK8KBzgBc6oxF2Ft2bMD3jXuDtGaPbQi69H2m 1rxnciVtMGBBPB45417KsxT3M0VGJk+LHLc4/NPGUUQvjoRmLJZPMh83W8oN84zjrdtJ CuVA== X-Gm-Message-State: AA6/9RkTSB2cpkIcFY54BEVQZE2El1VZVvbw2GiJsPww7ob8Xga8MGyQHtJrRHc2AbieRXCvYuT07Eoqs4vgpA== X-Received: by 10.129.77.84 with SMTP id a81mr26496657ywb.19.1476115323670; Mon, 10 Oct 2016 09:02:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.92.67 with HTTP; Mon, 10 Oct 2016 09:02:03 -0700 (PDT) From: Spencer Dawkins at IETF Date: Mon, 10 Oct 2016 11:02:03 -0500 Message-ID: To: "tsv-chairs@ietf.org" , tsv-art@ietf.org Content-Type: multipart/alternative; boundary=001a1140b7ac83d814053e84e1ea Archived-At: Cc: Mirja Kuehlewind Subject: [Tsv-art] Doodle poll for IETF 97 TSV Chairs/TSV-ART dinner X-BeenThere: tsv-art@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Review Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2016 16:02:07 -0000 --001a1140b7ac83d814053e84e1ea Content-Type: text/plain; charset=UTF-8 Dear TSV Chairs and TSV Area Review Team members, This is our usual Monday night dinner. Mirja and I are trying to get an early start on counting heads and collecting any dietary restrictions we'll need to know about. We're using a Doodle poll to collect RSVPs, at http://doodle.com/poll/zctvaz8yg8gx3rcy. Please let us know if you're able to come, and adding dietary restrictions as comments would probably be a great way to let us know. Thanks! Spencer and Mirja --001a1140b7ac83d814053e84e1ea Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear TSV Chairs and TSV Area Review Team members,

=
This is our usual Monday night dinner. Mirja and I are trying to get = an early start on counting heads and collecting any dietary restrictions we= 'll need to know about.=C2=A0

We're using a Dood= le poll to collect RSVPs, at=C2=A0http://doodle.com/poll/zctvaz8yg8gx3rcy.

<= div>Please let us know if you're able to come, and adding dietary restr= ictions as comments would probably be a great way to let us know.

Thanks!

Spencer and Mirja
--001a1140b7ac83d814053e84e1ea-- From nobody Tue Oct 11 11:27:23 2016 Return-Path: X-Original-To: tsv-art@ietfa.amsl.com Delivered-To: tsv-art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B8BA129580; Tue, 11 Oct 2016 11:27:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 rmiAsIP3O-DV; Tue, 11 Oct 2016 11:27:20 -0700 (PDT) Received: from mail-yb0-x236.google.com (mail-yb0-x236.google.com [IPv6:2607:f8b0:4002:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1630E129578; Tue, 11 Oct 2016 11:27:20 -0700 (PDT) Received: by mail-yb0-x236.google.com with SMTP id e2so11491018ybi.1; Tue, 11 Oct 2016 11:27:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=pz7RyqfkoWATqs92TIYIiPnqBn47naStZHwrGPNuxBA=; b=p06I213qdaehABD61V9CHwR3C23utfM00CsXT0XS4Oo2Wt17dK2kC6s1XOygTpL8kG 0ADJ7kwnDc4Nd8aPrXNkhAriH3PVg0MXzsyJE+o86Qhu+BnFa0jPUGacZcr6mKr1RpRf UwdoHPLFXQm/GBvbQvlB4/eZ5U3AQVZUj8pbCOliYwRvuFK+yIyIOBFc19FBHIGPXAGH 23SM7r6BaC+yHNqojVGmBZWCUyTectcyPhdxYFAZ3HfV4uD0Q9gaHSSkz+QDx093WGRd n3vqcaXIyhUtc7OV5AdQmcliWjKyI6UiZ872oaA5gZXUrVRxWKzhzaP6ysBJroK1eU/U RuFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=pz7RyqfkoWATqs92TIYIiPnqBn47naStZHwrGPNuxBA=; b=JMpyldBee3O14AeHO2zzGI3WbWpWbvThhZxClBQX7JgKfVZscaeu13TevgvpAvjdrB Kgk12GC4ctL0RPq2IQyRZdq3dVyRml6IqvMwJAPFg3bD8NrVI8vUnQOo44TieOFfM+GF Nsd1jPxmvoMLNWNJDgfB2qvvTwpSG2cE7qyLfCb1i5ociX5i/AXHm+rc7H8f7sDq6ZKe lNpINeQU6hOHbQgkXJnNS2leJ+9VSM2Cy9wTBngYOKzccKPdsQTw5scq30s3N6Cwh3X0 kXJeA8zzZa8UN9HxCTEqENBmeBoO+OAqNkf1AC3LtIJonXgZQYjI7slz2lhM3gAT1Zgw JwRA== X-Gm-Message-State: AA6/9Rmi089N9bnweHaprON75zcMp0PgJtyp9YQ1sdS3zWqh9DZd4AYZ5bYhZO7P5wftD3CfyLau5ckTiuZofQ== X-Received: by 10.37.171.234 with SMTP id v97mr4808131ybi.161.1476210439315; Tue, 11 Oct 2016 11:27:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.92.67 with HTTP; Tue, 11 Oct 2016 11:27:18 -0700 (PDT) In-Reply-To: References: From: Spencer Dawkins at IETF Date: Tue, 11 Oct 2016 13:27:18 -0500 Message-ID: To: "tsv-chairs@ietf.org" , tsv-art@ietf.org Content-Type: multipart/alternative; boundary=94eb2c0ce1f8d96c48053e9b0611 Archived-At: Cc: Mirja Kuehlewind Subject: Re: [Tsv-art] Doodle poll for IETF 97 TSV Chairs/TSV-ART dinner X-BeenThere: tsv-art@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Review Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2016 18:27:22 -0000 --94eb2c0ce1f8d96c48053e9b0611 Content-Type: text/plain; charset=UTF-8 Dear Invitees, On Mon, Oct 10, 2016 at 11:02 AM, Spencer Dawkins at IETF < spencerdawkins.ietf@gmail.com> wrote: > Dear TSV Chairs and TSV Area Review Team members, > > This is our usual Monday night dinner. Mirja and I are trying to get an > early start on counting heads and collecting any dietary restrictions we'll > need to know about. > > We're using a Doodle poll to collect RSVPs, at http://doodle.com/poll/ > zctvaz8yg8gx3rcy. > > Please let us know if you're able to come, and adding dietary restrictions > as comments would probably be a great way to let us know. > > Thanks! > > Spencer and Mirja > Magnus just noticed that I talked about Monday night (that's right), but put Sunday night (that's wrong) as the choice in Doodle. About 12 people have RSVPed "yes" so far, and changing the date seems to delete all the people who have already RSVPed. So, I'd like to leave the poll set the way it is - but we really are having dinner on MONDAY. If that seems confusing, please let me know, and I'll reset the poll. Thanks, Spencer, who seemed to be hurrying just a little too much on Monday - sorry! --94eb2c0ce1f8d96c48053e9b0611 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear Invitees,

On Mon, Oct 10, 2016 at 11:02 AM, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> wrote:
Dear TSV Chairs and TSV Area Review= Team members,

This is our usual Monday night dinner. Mirja a= nd I are trying to get an early start on counting heads and collecting any = dietary restrictions we'll need to know about.=C2=A0

We're using a Doodle poll to collect RSVPs, at=C2=A0http://doodle.com/poll/= zctvaz8yg8gx3rcy.

Please let us know if you= 're able to come, and adding dietary restrictions as comments would pro= bably be a great way to let us know.

Thanks!
=

Spencer and Mirja

Magnus just noticed= that I talked about Monday night (that's right), but put Sunday night = (that's wrong) as the choice in Doodle.=C2=A0

About 12 people have RSVPed &qu= ot;yes" so far, and changing the date seems to delete all the people w= ho have already RSVPed.

So, I'd like to leave the poll set the way it is - bu= t we really are having dinner on MONDAY. If that seems confusing, please le= t me know, and I'll reset the poll.
Thanks,
<= br>
Spencer, who seemed to be hurrying just= a little too much on Monday - sorry!
--94eb2c0ce1f8d96c48053e9b0611-- From nobody Wed Oct 12 06:23:03 2016 Return-Path: X-Original-To: tsv-art@ietfa.amsl.com Delivered-To: tsv-art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 857D212944D; Wed, 12 Oct 2016 06:23:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 wHQj9cMvRO_3; Wed, 12 Oct 2016 06:22:59 -0700 (PDT) Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C6B0129480; Wed, 12 Oct 2016 06:22:59 -0700 (PDT) Received: by mail.in.tum.de (Postfix, from userid 107) id EC8451C12CB; Wed, 12 Oct 2016 15:22:56 +0200 (CEST) Received: (Authenticated sender: ott) by mail.in.tum.de (Postfix) with ESMTPSA id 75CD71C1151; Wed, 12 Oct 2016 15:22:54 +0200 (CEST) (Extended-Queue-bit tech_rnlmk@fff.in.tum.de) To: Spencer Dawkins at IETF , "tsv-chairs@ietf.org" , tsv-art@ietf.org References: From: Joerg Ott Message-ID: Date: Wed, 12 Oct 2016 15:22:56 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: Mirja Kuehlewind Subject: Re: [Tsv-art] Doodle poll for IETF 97 TSV Chairs/TSV-ART dinner X-BeenThere: tsv-art@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Review Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2016 13:23:01 -0000 Wfm. Sun and Mon and leaving the poll as is. Jörg On 11.10.16 20:27, Spencer Dawkins at IETF wrote: > Dear Invitees, > > On Mon, Oct 10, 2016 at 11:02 AM, Spencer Dawkins at IETF > > > wrote: > > Dear TSV Chairs and TSV Area Review Team members, > > This is our usual Monday night dinner. Mirja and I are trying to get > an early start on counting heads and collecting any dietary > restrictions we'll need to know about. > > We're using a Doodle poll to collect RSVPs, > at http://doodle.com/poll/zctvaz8yg8gx3rcy > . > > Please let us know if you're able to come, and adding dietary > restrictions as comments would probably be a great way to let us know. > > Thanks! > > Spencer and Mirja > > > Magnus just noticed that I talked about Monday night (that's right), but > put Sunday night (that's wrong) as the choice in Doodle. > > About 12 people have RSVPed "yes" so far, and changing the date seems to > delete all the people who have already RSVPed. > > So, I'd like to leave the poll set the way it is - but we really are > having dinner on MONDAY. If that seems confusing, please let me know, > and I'll reset the poll. > > Thanks, > > Spencer, who seemed to be hurrying just a little too much on Monday - sorry! > > > _______________________________________________ > Tsv-art mailing list > Tsv-art@ietf.org > https://www.ietf.org/mailman/listinfo/tsv-art >