Sending a Sequence message on None flow is a protocol violation

[ujos]

03CommonFeatures.md Sending a Sequence message on an Unsequenced or None (one-way session) flow is a protocol violation.

Why is sending Sequence message inside the UDP multicast message is a violation?

[donmendelson]

Clarify--the phrase "one-way session" was intended to mean a point-to-point session in which all the application messages flow in one direction, not multicast. Actually, Unsequenced and None flows are not allowed in multicast (see section 5).

[ujos]

Still it is not clear, why is Sequence message not allowed in unicast UDP session?

[donmendelson]

Sequence is not only allowed on UDP, it is required for each packet.

Using a datagram oriented transport like UDP, each datagram carrying a sequenced flow, the Sequence message is key to detecting packet loss and packet reordering and must precede any application messages in the packet.

This language should be clarified to say that Sequence is required at the start of each packet on a non-multiplexed transport while Context is used instead on a multiplexed transport.

One thing that the spec does not address explicitly is an Unsequenced flow on a datagram oriented transport. If such a thing is allowed, then the either order does not matter or the receiver must rely on application layer sequencing.

[donmendelson]

Now it seems to me that the definition of a flow type should move up to the Common Features section in order to explain when Sequence or Context messages are necessary. Both Point-to-Point and Multicast have flows. The differences are:

• A point-to-point session has two flows, and each is either Recoverable, Idempotent, Unsequenced, or None. Only one of the flows can be None, indicating that the application messages flow in only one direction.
• A multicast session has exactly one flow, and it can only be Idempotent, or potentially with out-of-band recovery.

None of this discussion is intended to be a substantive change or enhancement, but rather an improved explanation of what is already intended.

[ujos]

Why is multicast idempotent?

[kleihan]

Multicast by itself is not idempotent, the application sending messages over multicast can provide an idempotent flow. The standard FIXP requires to declare a flow as part of the negotiation with the exception of multicast which is connectionsless and no counterparty to negotiate with. Hence FIXP defines the flow to be idempotent (recoverable only out-of-band) as there is little value in an unsequenced flow over multicast.

Do you have a use case where the idempotent flow over multicast is a problem?

[ujos]

Sorry, I do not understand. How impotence is related to recovery? Why Multicast stream cannot be out-of-band Recoverable?

From 05MulticastSessionProtocol.md:

FlowType = Recoverable | Idempotent

[kleihan]

Don wrote above "A multicast session has exactly one flow, and it can only be Idempotent, or potentially with out-of-band recovery." This means that multicast stream can be recoverable, not sure where the misunderstanding comes from. It just cannot be in-band recoverable because this would require the recipient to have the ability to request lost messages. As multicast only flows in one direction this is not possible.

Idempotence is related to recovery when the application sends snapshots which allows the recipient to re-establish for example the current state (continuous, auction, halted,...) of an instrument on a trading venue (even though the recipient missed earlier messages informing him about a state change). The application of the recipient can recover in the sense of having the correct state again.

[ujos]

A multicast session has exactly one flow, and it can only be Idempotent

"Only" word confuses me

[kleihan]

The flow itself over multicast can only be idempotent. However, recovery can be supported by another flow, hence the expression "out-of-band". This other flow is then not idempotent but recoverable.

[donmendelson]

On a UDP multicast...

• Recoverable is not possible in-band because RetransmitRequest cannot be sent back to the producer
• Unsequenced does not allow packet loss detection
• None is illogical because there is only one flow

[ujos]

Recoverable is not possible in-band because RetransmitRequest cannot be sent back to the producer

That is obvious. How about Recoverable flow with out-of-band recovery process?

[kleihan]

This is possible but what is the use case? Why not in-band?

[donmendelson]

Hanno, the context of the question was for multicast.

The working group discussed out-of-band recovery, but we have not fully specified it. Proposals are welcome.