Re: [Webpush] question on Urgency semantics in draft-ietf-webpush-protocol-04

Martin Thomson <martin.thomson@gmail.com> Thu, 07 April 2016 18:55 UTC

Return-Path: <martin.thomson@gmail.com>
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 23D6D12D6CC for <webpush@ietfa.amsl.com>; Thu, 7 Apr 2016 11:55:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 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, 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 hJHvyHWzZg-L for <webpush@ietfa.amsl.com>; Thu, 7 Apr 2016 11:55:57 -0700 (PDT)
Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) (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 2478712D6C1 for <webpush@ietf.org>; Thu, 7 Apr 2016 11:55:57 -0700 (PDT)
Received: by mail-ig0-x234.google.com with SMTP id f1so160502937igr.1 for <webpush@ietf.org>; Thu, 07 Apr 2016 11:55:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-transfer-encoding; bh=OFMrTUaZ6JtKnGg6UVUykuwq+sEdJH2VgzL4X9yWy1k=; b=R0Ec+zrx/yoYjshXVlEjvcRQ7vKXwtcdEhi0AD/AuGS2wz388g3QjPfgwrsmm4pPrY vVaot6SEDJGpZw1v4pMFn6debuNIcZHA6oE/5u7VTGB3yI26I04iEKAE6zxBXX8y9Bkp P56N5viUJawYFBiHzDPB7oVdMeRZiYObpdWDyklutgBerEC4dEfGg7LlDrKtq1XLgGBK pf5tuLtaiQ5tgfxuoSE7mPP+/Q8c1LPICWOFwnJfUSdlQ+ZINZzy/V6Rxje71SvbEKRI LV7IolBm/9IZdwssDUOPP6sqp2V+Rt6szlO/OOis0+Rnt0BpqkgXThUmk5VeQUvBzwQg ++tg==
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:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=OFMrTUaZ6JtKnGg6UVUykuwq+sEdJH2VgzL4X9yWy1k=; b=XoZvTUjBqPMzaSZ+4ixn/oZRQk7E6TkYuhUkrHVnJ3AP1nezcqLG+NAEdx+XHZt2SY z3JY/FfEnP+bxdLBALNEYJON8PZEZ0AWqP0f9zrjytw0ehFUjLKlx+42Qc3re25Ft+zy XgNITT5Df1gnj0nbujwCgzxwUtVzgPReQsS4HuNpvTlDXRmZ/C5SsynR1NFxaBr+fHHz e0fc2O6ustz/xMY25t8eEJTQdBevxeMCsMjPNGh9oHyM2hbIwXpm3bNqlq7iUBRZBtgS 4ZLRe8G7z7imk4a/9JNObi5rZcSjPVVrktZOKGTsPHmCbwrb9QA+24w5MJT/gLrBTRK4 VO2w==
X-Gm-Message-State: AD7BkJKURiXE+0s4sHpOVGjui72JEFjf6NpmbSzdrN3nwrpLtLozuT9veJmZO7tCxlE7hUj8HUMj0Glm9ItNaw==
MIME-Version: 1.0
X-Received: by 10.50.23.80 with SMTP id k16mr31693234igf.94.1460055356490; Thu, 07 Apr 2016 11:55:56 -0700 (PDT)
Received: by 10.36.43.5 with HTTP; Thu, 7 Apr 2016 11:55:56 -0700 (PDT)
In-Reply-To: <D32C044E.A68E%d.thakore@cablelabs.com>
References: <D32C044E.A68E%d.thakore@cablelabs.com>
Date: Thu, 7 Apr 2016 15:55:56 -0300
Message-ID: <CABkgnnXZcMu5G9pTE1oCA=m31gLFsGkebYgaAhV3rBdm3r-u7Q@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: Darshak Thakore <d.thakore@cablelabs.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/webpush/YRXDm_BByMBdyzJ8vIE6Mo99KRk>
Cc: "webpush@ietf.org" <webpush@ietf.org>
Subject: Re: [Webpush] question on Urgency semantics in draft-ietf-webpush-protocol-04
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: Thu, 07 Apr 2016 18:55:59 -0000

A timely question, or set thereof.

I was most of the way through
https://github.com/webpush-wg/webpush-protocol/pull/82

1. The UA should be able to filter out messages of lower urgency, the
above PR clarifies that point.
2. We can't stop an AS from gaming the system, but we could treat too
many high-urgency messages as a DoS attack (more on this later)
3. There are cases where accepting messages entails more work than
would be ideal.  There are some messaging channels where the delivery
of a certain amount of data causes a dramatic increase in cost.  For
example, the paging channel in a cellular network.


On 7 April 2016 at 15:34, Darshak Thakore <d.thakore@cablelabs.com> wrote:
> Hi all,
>
> In reviewing the 04 version, I was hoping for some comment/clarification on
> the Urgency semanics:
>
> Section 6.3 - Urgency header
>
> The last paragraph - “An absent Urgency header field indicates that the
> request is to be forwarded at “normal” urgency…"
>
> I’m assuming this statement applies to the “Urgency” header only when it is
> used by the AS to send the message to the PS. Correct? An absent “Urgency”
> header field in the request from the UA to PS should result in all messages
> being retrieved. Am i interpreting it correctly ?
>
> Also in general, i’m trying to understand how the “Urgency” header actually
> works here. Once a radio is up for communication, you typically want to
> complete as much of data communication as possible so that you can go back
> to sleep for an extended period. If we had the following scenario;
>
> Three applications have subscribed with the PS so we have a subscription set
> consisting of these three. Now the following messages are sent
>
> AS1 -> PS : Sends 5 messages without the Urgency header so all 5 are
> “normal"
> AS2 -> PS : Sends 2 messages with “high”, 5 with “low” and 5 with “very-low"
> AS3 -> PS : Games the system and sends 5 messages with “high”
>
> Now before AS2 sends any messages, if the UA polls the PS with the Urgency
> set to “high”, it doesn’t get any pushes. If the UA polls the PS
> subsequently after AS3 sends the messages again with Urgency set to “high",
> it will receive 7 messages (2 from AS2 and 5 from AS3). The other 15
> messages (from AS1 and AS2) remain outstanding.
>
> In the above scenario, the pending 15 messages may expire before getting
> delivered and requiring the PS and AS# to maintain state, deliver back
> “expiration” receipts and retry delivery (this cycle may happen a couple of
> times). Is all this complexity only to allow the device’s radio to be in
> full-power communication mode for the duration of the 7 messages instead of
> (7+15) messages or is there any other benefit i’m missing ? Given that the
> radio was in full power mode along with a “fully-primed” TCP connection from
> the UA to the PS, are we really saving any significant energy by not sending
> those 15 messages ? Also there does not seem to be anything that stops a
> particular AS from gaming the system and sending all its messages with
> “high” urgency.
>
> My main goal here is to understand what precise benefit we are providing
> with the Urgency header.
>
>
> Regards,
> Darshak
>
> _______________________________________________
> Webpush mailing list
> Webpush@ietf.org
> https://www.ietf.org/mailman/listinfo/webpush
>