VTP 2.0 Proposed Recommendation: Request for Comments

Public discussion page for the IVOA VTP 2.0 Proposed Recommendation.

The latest version of the VTP Specification can be found at:

• http://www.ivoa.net/documents/VOEventTransport/20170114/index.html

Reference Interoperable Implementations

• Comet (Python)
• Dakota VOEVent Tools (C#/.NET)
• PyGCN (Python; only implements subscription)
• GCN client demo (C; only implements subscription)

Comments from the IVOA Community and TCG members during RFC period: 2016-05-31 - 2016-07-16

Comments from TCG members during the TCG Review Period: 2016-05-31 - 2016-07-16

WG chairs or vice chairs must read the Document, provide comments if any and formally indicate if they approve or do not approve of the Standard.

IG chairs or vice chairs are also encouraged to do the same, although their inputs are not compulsory.

TCG Chair & Vice Chair ( _Matthew Graham, Pat Dowler )

Applications Working Group ( _Pierre Fernique, Tom Donaldson )

I found the document clear, easy to read, with a lot of useful examples and diagrams.

Concerning the relation and possible problems with other VO protocols, I just saw one potential difficulty with the last version of the Registry Identifier document. In VTP, each author, each subscriber and each broker uses a unique IVOID for its identification. Thus all of them must be fully registered in the VO registry. This constraint can be reasonable for authors and brokers, but could be a barrier for subscribers which just want to receive VOevents, and not necessary register them in the VO registry.

Variations on this concern were widely expressed, so I will try to address them all here.

It is correct that authors and brokers should be registered with the Registry. However, the mechanisms for doing this are not yet in place (see http://www.ivoa.net/documents/VOEventRegExt/index.html for work in progress). Since the protocol is currently deployed “in the wild” without registry support, I do not think it's necessary to block VTP until VOEventRegExt has been adopted, but I will add a “forward reference” and explain the expectations here.

The requirement that subscribers provide an IVOID (was IVORN; apologies for the outdated terminology) is a relic from earlier versions of the protocol. It is not required for operation of the protocol as described. However, some older software will still include the element in response messages, and, given that, I suggest we should not forbid it. However, I've checked that neither Dakota nor Comet, as the two most (only?) widely deployed brokers, will not choke if the subscriber does not include an IVOID in their response messages. I have therefore edited the text to make it optional for subcribers to include an identifying URI, which may be an IVOID. I believe this will address all the concerns while not breaking current implementations. -- JohnSwinbank - 2016-12-30

If this registration step is not a problem for the potential VO-event participants, I have no objection to promote this document in IVOA Rec status

--

Now, I remove my App working group hat, and as I read the document and try to understand VTP, I have two questions concerning the protocol VTP itself:

A) About the robustness of VTP, what could be the consequences of a temporary out-of-order of a broker notably in case of 2 brokers links (similar to figure 1 page 3).

I assume 2 connected brokers A and B, each on them with their own subscribers and authors:
0) The broker A stops (failure, maintenance, or whatever...)
1) All its subscribers will start their re-connection loop with a delay geometrical law (1s, 2s, 4s, ...10mn...).
2) When the broker A is restarted, most of the subscribers will be not immediately reconnected
(geometrical law consequence)
3) But the broker A will immediately reconnect to broker B
4) The broker B will send all the backlog messages to broker A (stacked during the broker A out-of-order time)
5) The broker A will immediately forward these messages to its "already" reconnected subscribers...
6) Consequences : most of the subscribers of broker A will just miss the backlog messages from broker B

To avoid this bad effect, I imagine that the broker A should wait atleast the max reconnection delay time to be sure that all its subscribers are ready to receive before re-subscribing itself to broker B. If I'm right, it could be important to notice this point in the document, and thus, explicitly provide the max reconnection delay time (10mn ? 1h ? 1 day ?)

This is a great question: thank you.

In fact, though, it rests on a faulty premise. There is nothing in the spec which requires broker B to buffer a backlog of messages to forward to broker A when it reconnects. Indeed, such a buffer is not, in general, possible: brokers are not required to maintain a log of their subscribers, and there's no way for a broker to know if a given subscriber has disconnected deliberately, because they are no longer interested in receiving events, or due to some sort of fault. Indeed, assuming (as above) that we relax the requirement for subscribers to have registered IDs, there is no way for the broker to know whether a connection is from a new subscriber or from an old one reconnecting.

I don't regard this as a flaw in the protocol, so much as a use case which is intentionally not covered. Per the VOEvent standard, a subscriber who has dropped offline events should turn to a VOEvent repository (e.g. http://voeventdb.4pisky.org/) to catch up on what has been missed.

The introductory text has been updated in an attempt to make this clearer. -- JohnSwinbank - 2016-12-30

B) I have also two remarks which are related to the scalability of VTP:

1) The protocol is simple - good thing in VO context - but probably quite limited in term of number of subscribers per brokers due to the TCP connection keep alive constraint. This constraint can be difficult to insure for the brokers (the number of TCP connections is sytem kernel dependent), and also for network equipments such as firewalls or NAT equipements which have to manage individually each opened TCP connections. I imagine that we are speaking about a few subscribers per broker (a few dozens, not really more). May be this point could be specified in the document.

Yes, this is a fair point. See also Swinbank (2014; https://arxiv.org/abs/1409.4805) for a more detailed discussion of VTP scalability, including the number of subscribers. I have mentioned this in the text. -- JohnSwinbank - 2016-12-30

2) It seems quite easy to write an VTP author, but the broker and the subscriber could be more difficult to implement notably due the lack of an unique identifier for a given VO-event (§8 in the document). As said in the document, that forces them to memorize all messages to be able to bit-for-bit compare them (*) for avoiding duplication or cycling effects. The document specifies that this comparison could be realized by an hash key method. But the hash method is not perfect in the sens that 2 different messages can potentially have the same hash key (no injectivity), notably if the content of the messages are globally similar. If VTP is used for a few messages, no problem. If this protocol is used more intensively, time to time a message will be ignored as wrong duplication. At this opposite, if this comparison task is not correctly implemented on the broker level there is a non negligible risk to flood the VO-event network. That also implies that there is no possibility to extend the content of a message, for instance by the brokers for incrementing a step counter in order to reduce the potential risk of cycling messages, or to store the path used by a VO-event message.

I agree with the gist of all of the comments here. I regard the lack of a unique per-event identifier as a significant flaw in the VOEvent standard — one which, unfortunately, it is outside the scope of VTP to address.

That said, I do think the dangers of hash collisions are extremely small, even on busy event networks, and I don't believe that events with similar content are likely to hash to similar values. -- JohnSwinbank - 2016-12-30

-- PierreFernique - 2016-09-23

Data Access Layer Working Group ( François Bonnarel, Marco Molinaro )

This document is well written and clear enough for the reader. Some points should be clarified anyway:

- How far is the IVOID of each node necessary to the whole process and what will be the registration process for that ?

See the discussion above. -- JohnSwinbank - 2016-12-30

- Reference to new IVOA identifiers specification and SSO specification should be included.

Reference to new IVOA ID spec added.

Material on cryptographic signatures substantially reworked and trimmed, and reference to SSO Profile PR added. -- JohnSwinbank - 2016-12-30

- answers to previous remarks on recovery procedure will be useful

As soon as these points are answered we support the recommendation of this specification.

- Apart form that a demonstrator could be useful to check the behaviour of a network of nodes with peculiar attention to what happens in case of broker failure and recovery.

Written to François to clarify what “demonstrator” means here. -- JohnSwinbank - 2016-12-30

-- FrancoisBonnarel MarcoMolinaro - 2016-11-28

Data Model Working Group ( _Mark Cresitello-Dittmar, Laurent Michel )

Introduction: it may be worth to give an order of magnitude of the expected VOEvent traffic in large infrascrutures (LSST...)

Added a brief note to this effect. -- JohnSwinbank - 2016-12-30

Acknoledgements: A first name would be welcome: ...Robert Seaman (NOAO). [J.] Swinbank....

Done. -- JohnSwinbank - 2016-12-30

Section 3.3: A brief sentence setting the difference between "VOEvent messages" and "Transport messages" or saying what "Transport messages" are would be helpful.

This already exists in a footnote. I think that's all that's necessary, but do let me know if you disagree. -- JohnSwinbank - 2016-12-30

Section 4.2 and 7.x: What happens if a node does not respond to a message?

Good question!

Failure to receive an acknowledgement should be interpreted as a temporary failure: the sender should assume that the recipient has not successfully received the message, but there has not been a permanent failure which would prevent the recipient from ever accepting the message. The sender may wish to attempt to re-send the message.

Authors submitting to brokers likely will wish to retry, as they should assume their event has not been sent out for distribution.

Brokers sending to subscribers likely will not wish to retry. At the discretion of the broker, repeated failures to receive timely acknowledgement from a subscriber may be grounds to terminate the connection.

I've added wording to §§7.1 & 7.3. -- JohnSwinbank - 2016-12-30

Section 6.2: Requesting the subscribers to include an IVOID in their responses supposes that they are registered in the registry. Is that true? May the <Origin> element be empty? This point must be clarified.

Please see the discussion above. -- JohnSwinbank - 2016-12-30

Section 8: Contrary to Apps, I've no objection about using hash codes to identify messages by their content; hash values are very different even if just one single bit has been changed.

Although the scope of the document is the transport protocol, some clarifications about the connection between a VOEvent infrastructure and the registry would be nice. Here are some questions I had upon while reading the document: Should brokers declare their added-value behaviour in the registry? How can an author locate a broker? and a subscriber?

These are good and valid questions, which I believe are outside the scope of this document. I will add a "forward reference" to the VOEventRegExt document, which is still in preparation. -- JohnSwinbank - 2016-12-30

Hereafter the clarifications I'm suggesting, I approve the document.

-- LaurentMichel - 2016-09-26

Grid & Web Services Working Group ( Brian Major, Giuliano Taffoni )

Section 8, De-duplication: The method of determining if messages are equal seems awkward. One could use, for example, a UUID that is generated when the event is constructed to avoid any ambiguity. Because each broker may choose a different algorithm for equality, they cannot communicate with each other about an event. (Even if that requirement isn't in the specification now, it could be later.)

It's my fervent hope that a future revision of VOEvent will provide some means of uniquely identifying VOEvents!

I have added a note to §8 of the document to note the possibility that if, in future, some unique event identifier were to become available, it should be used. -- JohnSwinbank - 2016-12-30

Even better would be if the brokers could operate in a stateless manner. I.e. Not having to remember which events have come by. Was there consideration in building the history of brokers visited into the event itself?

The origins of the protocol predate any of the currently involved players, so it's hard to be sure exactly what was considered!

A naïve consideration of this idea would seem to break the sharp separation of the VOEvent itself from the transport layer. However, I do wonder if a SMTP-like "envelope" transmitted together with the event could provide the best of both worlds.

The aim of the current work is to formalise the system that has already been de-facto adopted and is in current use, so I don't think we can change that here. However, this should certainly be considered for a future revision of the protocol. -- JohnSwinbank - 2016-12-30

In section 9, I think it would be appropriate to reference the IVOA Single Sign-On Profile document for more information on how to use digital signatures.

Done. -- JohnSwinbank - 2016-12-30

I approve this document.

-- BrianMajor - 2016-10-03

Registry Working Group ( _Markus Demleitner, Theresa Dower )

Sect. 6.1f use the term IVORN, which was deemed hopelessly ambiguous during the creation of Identifiers 2.0 (which had attempted to properly define it). So, we've deprecated it -- just call it IVOA Identifier or IVOID and be done with it (*).

Done. -- JohnSwinbank - 2016-12-30

Also in 6.1, you say "should normally include a timezone". You've probably seen the discussions about timestamp fromats in the context of UWS and DALI -- perhaps you could prevent future inconsistencies with the rest of the VO by saying "This [time and date] should include a ``Z'' timezone indicator. If the timezone indicator is missing, clients should assume UTC. The use of other timezone indicators (and, hence, timezones) is severely discouraged." (and similar in the following sections).

I'm not sure that I follow the controversy here, but I see no harm in rewording. -- JohnSwinbank - 2016-12-30

Still in 6.1, the sample document references a non IVOA-namespace and schema location. I realize it's probably too late to change the namespace. Perhaps you could still comment on this and at least use the ivoa.net schema location (http://ivoa.net/xml/Transport-v1.1.xsd, I think)?

Have submitted the schema for inclusion on ivoa.net, and updated the reference to the putative new location. -- JohnSwinbank - 2016-12-30

I'm not terribly happy about 9.2, as the authentication scheme proposed isn't mentioned in the SSO document that we're reviewing almost simulataneously. If this wasn't advertised as "finished tech just being codified", I'd say it's a bit embarrassing to, in effect, have conflicting recommendations (SSO: "Auth schemes approved are..."; VTP: "...something we don't particularly care about.").

Have submitted the schema for inclusion on ivoa.net, and updated the reference to the putative new location. -- JohnSwinbank - 2016-12-30

Things being what they are: if this is deployed and implemented, so be it (except that then I think you should say what XML signature scheme actually is used). If it's not, however, can't you just put in "to be specified in 2.1"? [All this leaves aside the question of what kind of security is achieved by the protocol proposed -- over a plain TCP connection with all its susceptability to eavesdropping and hijacking, that's probably limited in the first place].

This section has been substantially reworked. -- JohnSwinbank - 2016-12-30

Typos and similar

p. 4 "...set of brokers which subscribe/r/ to each other's" (*)

"The Transport Protocol, hereafter VTP" -- perhaps actually put a "VOEvent" in front of "Transport" so the acronym matches? (*)

Fixed. -- JohnSwinbank - 2016-12-30

Provided at least the points marked with (*) are somehow addressed, we approve.

Semantics Working Group ( _Mireille Louys, Alberto Accomazzi )

I have read the PR-VTP-2.0-20170114.pdf version of this specification and found no overlap neither contradiction with the existing IVOA specifications dealing with semantics.

I approve the document.

-- MireilleLouys - 2017-01-25

Education Interest Group ( _Massimo Ramella, Sudhanshu Barway )

Time Domain Interest Group ( _John Swinbank, Dave Morris )

Data Curation & Preservation Interest Group ( Françoise Genova )

Operations Interest Group ( _Tom McGlynn, Mark Taylor )

This seems like a protocol for which a validator should be both straighforward and important. This seems particularly true for the broker role -- where the handling of message loops would be a particular concern -- but simple validation of the Author and Subscriber roles would be helpful too.

Outside of the OIG's particular concerns, this seems to be a clearly written, easily understood and well bounded protocol. However the need to stay continuously connected seems dangerous. If the connection is interrupted for whatever reason there seems to be no way to recover a missed alert. A protocol that explicitly supported (but did not require) brokers providing subscribers with the set of recent events immediately after connection would seem more robust. If a broker optionally allowed users to ask about any events seen in the past hour (or some other TBD and possibly broker dependent time) then a subscriber could potentially recover any events they might have missed. Might also help with the message loops issue.

I agree with all of the comments here, but do not propose to adopt them in this version of the protocol for fear of breaking existing implementations. We'll put this on the slate for the next revision. -- JohnSwinbank - 2016-12-30

-- TomMcGlynn - 2016-09-27

Knowledge Discovery Interest Group ( Kaï Polsterer )

Theory Interest Group ( _Carlos Rodrigo )

Standards and Processes Committee ( Françoise Genova)