[Standards-JIG] Internet-scale subscription protocols

Benjamin Carlyle benjamincarlyle at optusnet.com.au
Tue Nov 7 21:31:37 UTC 2006

On Sun, 2006-11-05 at 15:09 +0100, Ralph Meijer wrote:
> On Sun, 2006-11-05 at 16:36 +1000, Benjamin Carlyle wrote:
> > I have been trying to get my brain into JEP-0060 from the perspective of
> > the more HTTP-oriented subscription patterns I have worked with and read
> > up on in the past. In particular, Rohit Khare's dissertation on
> > decentralising REST. The XMPP approach jumps the rails a bit from what I
> > am used to and I would like to understand whether or not it meets my
> > requirements.
> Before going into your questions below, how, in your view, does XEP-0060
> (we renamed all our extension protocols to XEP recently) jump the rails?

Well, in particular the way that XMPP seems to build a network on top of
the network. The environments I am familiar with will have separate
TCP/IP connections for associations between different nodes and will
expose flow-contol behaviours in an obvious way. I believe that XMPP
clients will usually have a single TCP/IP connection to "the
network" (ie their XMPP server) and then that server will forward the
message onwards. This is similar to HTTP layered proxying, but looks
more structured.

I was actually under the impression that the XMPP network was serving a
multicasting role in the subscription. I think by your response that I
was wrong on this point and that the notification has to be sent
multiple times by the pub/sub service to its XMPP server with different
routing headers.

Another difference is the distinction between the pub/sub service and a
publisher. While this difference has always been implicitly allowed by
previous attempts that I have seen, it has not been a cornerstone of the
protocol. Whatever relationship a publisher has to its pub/sub node was
a private affair, and often the publisher would be part of the process
offering pub/sub services. I have to admit that when reading the spec
for the first time I wondered how much of complexity could be reduced by
removing the publication protocol, or moving it to a separate
specification that could evolve independently.

The final aspect of XMPP that I don't feel I appreciate well enough to
understand the protocol as a whole is how authentication and trust
mechanisms fit into the picture. Previously I would have guessed that
explicit digital signatures would be required on notifications to ensure
they came from an appropriate source. However, I'm suspicious that XMPP
is encapsulating a trust mechanism in the network that I haven't come to
terms with yet. I'm suspicious that a subscriber can trust the message's
source address is accurate without needing any additional assurances
that the source is not a man in the middle.

>                                 The publish subscribe service has these
> responsibilities:
>  * Keeping topics (nodes) with their associated subscriptions

It is interesting to me to observe the relationship between topics and
resources. The GENA protocol allowed subscription to a resource, and
tried to define topics within that resource. I think it turns out to be
simpler just to choose the right resource to subscribe to in the first
place. I think you effectively do this by making the resource a
combination of pub/sub node and topic path.

> > 2) That is be capable of dealing with notifications that come in faster
> > than they are being delivered without a meltdown.
> This seems like an implementation issue, not a protocol issue.

Well, here is a common meltdown scenario in the environments I work

* A pub/sub node has one publisher and two subscribers
* One subscriber is able to accept 100 bytes of message per second. The
other, 200 bytes.
* A publisher produces 200 bytes of messages per second.

What should the pub/sub node do?

1. Buffer on behalf of the subscriber until the messages get through.
This works for while, but the slow subscriber will see more and more out
of date messages as the buffer grows. The buffer will also eventually
consume all resources at the pub/sub node leading to a meltdown
2. Block the publisher until the message has been delivered to all
This reduces the flow of the fast client to the same as that of the slow
3. Summarise the data
This discards 100 bytes of data per second, collapsing it in a way that
as much information as possible is retained. Both slow and fast client
recieve data at the rate their connection characteristics allow, however
the slow client recieves an abridged form of the notification. Explicit
selection of the summarisation algorithm as part of the protocol would
help with this case with "fold" being a likely default.

I'm not sure what will happen in this scenario under 0060. I'm not even
sure that that pub/sub node will be aware that it has slow clients. Will
the pub/sub's connection to its xmpp server block (blocking all
traffic)? Will the xmpp server itself start to buffer infinitely? Will
some form of error occur in the transmission of the message? Will the
slow client be ejected from the xmpp network?

> But I suppose summarization is dependent on what type of information you
> are publishing. For example, if you have a node that publishes news
> items (maybe using Atom), I could imagine digests of multiple entries in
> one notification. But this limits the ability to access retrieve
> distinct entries as publish-subscribe items.

Yeah, it may be best to first attempt to cut down the contents of the
article. If the data is 2x100byte articles per second, the slow client
might still hope to recieve 2x50byte article summaries. This would allow
them to go to the perminent url of the atom entry to read the full
article at their leisure. For now they may even be happy seeing only the
title if bandwidth limits really start to kick in.

> For another type of data, the current ambient temperature for example,
> it could be sufficient to just send less notifications for particular
> subscriptions.

Quite. The freshest data is most likely to be relevant, so just transfer
that. They can analyse the historical records at their leisure by
heading off to the appropriate web site. For now, they just want the
number on their monitor to show an up-to-date figure.

> >      Differential flow control. A slow client should not prevent fast
> >      ones from getting updates.
> XEP-0060 notifications are sent using <message/> stanzas. These are
> one-off messages with no acknowledgments. So slow clients should not
> influence fast ones.

I may be thinking too simply here, but don't both message stanzas go
down the same TCP/IP connection?

> >      Localised resynchronisation. A client need not reach back to the
> >      origin server for the current resource status if its immediate
> >      server is already handling the subscription.
> This would be one requirement for the to-be-written specification.

Well it sounds like you have this solved for the moment with your
persistent events. If layered notifications are introduced you would be
looking to have that persistent state at each layer, methinks. When it
comes to layering, is there any way to ensure that the layering graph is
efficient? Is there any hope that you can deliver all australian
notifications to the aussie pub/sub server while all chinese ones go to
the zh one? How geographically/topologically-aligned are existing xmpp

> >      Patch updates. For large resources (especially lists), the ability
> >      to deliver a message that indicates the change from last time,
> >      only. Not the whole state.
> XEP-0060 allows for notifications without payloads. If a payload was
> provided with the publish, and the node is configured to be persistent,
> an entity may retrieve the payload at a later time by sending a request
> with an item identifier that is sent with the payloadless notification.

I'm actually more interested in a list of 100000 alarms. If my user
acknowledges one, can I send a notification that the single alarm has
changed rather than sending the whole list again? I think your mechanism
currently allows for subscription to the list or subscription to the
changes, but not really both. I guess I would just like to be able
synchronise something big that usually changes in fairly minimal ways
after the initial synchronisation. I have this sort of thing in my
draft, but rely on a separate PATCHNOTIFY request being sent to clients
for these patch updates.

> >      Dial-back. Pub/Sub can be an amplifier of denial of service
> >      attacks. The subscription mechanism must be able to detect
> >      when its notifications are being treated as spam and end the
> >      subscription.
> I suppose much like mailing list software, an implementation of a
> publish-subscribe service could remove subscriptions for entities that
> have repeatedly sent back errors in response to a notification. Is that
> what you mean?

I guess what I am talking about is really just ensuring that a
particular subscriber isn't subscribed by someone nefarious. That they
really issued the subscribe request themselves. I am suspcious that the
XMPP network already has trust mechanisms in-place to ensure this
occurs. The systems I have worked with in the past have to apply a
specific trust layer on top of the subscription. This either leads to a
full-blown signature or certificate exchange at subscription time, or to
dumbed down measures such as dial-back to ensure that whomever is
recieving the requests actually wants them.

I guess the other case that this sort of behaviour handles is when a
client is subscribing automatically. If the client restarts, it may not
know what state it left things in previously. It may reissue the
subscription. I think you handle this by giving that client the
subscription they already have, is that right? Otherwise you would be
looking for a way for the duplicated subscription to be cut down on the
next notification.

> As a last remark I want to point out that XEP-0060 should probably play
> hand-in-hand with more general specifications such as Advanced Message
> Processing (AMP, XEP-0079) for expiring notifications or unreachability
> handling, Extended Stanza Addressing for multicasting identical
> notifications to entities that share a 'home' server, and the Jingle
> suite for doing out of band transfers of large payloads (maybe similar
> to Publishing SI Requests (XEP-0137)).

Ahh, so some multicasting can be expected in future. What rate will the
home server accept messages at when it itself as a slow and fast client?


More information about the Standards mailing list