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

Thanks, PR 82 addresses my question around Urgency header usage.

Regarding point #2 below, would it make sense to provide some text that
declares this as ³fair-warning² and that PS¹s should address this (maybe
in the security considerations section)

Darshak

On 4/7/16, 12:55 PM, "Martin Thomson" <martin.thomson@gmail.com> wrote:

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