Re: [Webpush] Receipt subscription follow-up

[Costin Manolache <[e-mail]>]

Yes, traffic is not uniform. For example if one network has an outage - a
lot of saved messages will
be delivered when the network recovers, resulting in a spike of receipts,
which may bring down
some AS servers - with cascading effect. And very little they can do about
it.

Also it's hard for PS to load balance without some feedback. Delete would
provide the feedback
and support flow control - at least if it is sent on the same h2
connection. If it's send on a different
connection - who knows where it'll be load balanced, and it gets quite
tricky to correlate.

One option would be to have multiple GET requests on the receipt resource -
each would get
a MAX_CONNECTION promises (receipts), after that the AS would need to make
another GET.  They can also have 2-3 concurrent GET requests if they want,
and manage
the flow by (outstanding GET * max_receipts_per_get).

May still lose some receipts (no confirmation), but ok if spec is clear
that receipts are best
effort.

Costin

On Wed, Apr 27, 2016 at 6:18 PM Martin Thomson <[e-mail]>
wrote:

> On 28 April 2016 at 10:51, Brian Raymor <[e-mail]>
> wrote:
> >
> >
> > Martin Thomson <[e-mail]> wrote:
> >
> >> On 28 April 2016 at 10:29, Brian Raymor <[e-mail]>
> wrote:
> >>> PS can already rate control an AS:
> >
> >> This was about the reverse, having rate control on the delivery of
> >> receipts to the AS.  It's possible that a PS could overwhelm an AS
> >> with these.
> >
> > I understand - my point is that the AS is creating its own problem. It's
> requesting
> > too many push messages with receipts and then failing to scale when
> receiving the
> > receipts from the PS. In this case, the AS needs to be encouraged by the
> PS to slow
> > down its rate of requests that are generating those receipts.
>
> It's not that easy.  An AS could send messages out over several time
> and still be flooded with receipts in a sudden spike.
>