Correct example to reconcile 4.6.2.2 with 7.3.4.2

[danjmarques]

Reading the example in #42, where there is

 RetransmitRequest FromSeqNo=1000 Count=20
 Retransmission FromSeqno=1000 Count=5, followed by 5 application messages

Would it be correct for the re-transmitting side to issue

 Retransmission FromSeqno=1005 Count=5, followed by 5 application messages

without a second RetransmitRequest?

Given the example in 7.3.4.2, where the re-transmitting side satisfies a single RetransmitRequest with two Retransmissions, it seems like that behavior is allowed.

However, if that is allowed, I'm confused, how would the requesting side know if it would need to make a second request or not?

[donmendelson]

I agree that the example should be corrected to show a second RetransmissionRequest as you suggest.

[danjmarques]

@donmendelson -

The first paragraph of 4.6.1 seems to state that multiple Retransmissions are allowed:

When receiving a recoverable message flow, a peer may request sequenced messages to be retransmitted by sending a RetransmitRequest message, which should be answered by one or more Retransmission messages (or with a Terminate message if the request is invalid).

Is this paragraph in error?

Essentially, my question is: "Does the spec allow a counterparty to respond to a single RetransmitRequest with multiple Retransmission messages?". If the answer is "no" (as it seems to be, given your suggestion to correct 7.3.4.2) then that paragraph is in error; If the if the answer is "yes" or "undefined" (which means it is up to the counterparties to determine this behavior), then I think the spec needs to make clear that the choice is up to the implementors, and 4.6.2.2 needs to be clear that it is just a suggested solution.

(Alternatively, the intention of the spec could be to mandate multiple responses to a single request, if there were more messages than fit in a batch, but this would mean that the document was very out of alignment with the intention of the spec, so this seems unlikely).

[donmendelson]

@danjmarques the intention of the design is that real-time messages should not be blocked by long retransmissions. Thus, retransmissions should be sent in blocks of limited size, and the retransmitter should await another request before sending the next block as flow control. The spec states that pacing is the responsibility of the retransmitter.

The phrase "one or more Retransmission messages" does not seem in keeping with the spirit of the design.

I consulted the XMIT spec (no longer available online) on which FIXP was based and it says:

The peer producing the flow responds with a Retransmission message beforere transmitting messages, or with a Terminate message if the request violates the protocol

No "one or more" -- not sure where that came from. I suggest we strike it in errata or a future version.

[danjmarques]

@donmendelson - Thanks for your responses. The intention is now very clear.

[danjmarques]

@donmendelson - BTW, would you prefer that I open a separate ticket for the suggested changes to the first paragraph in 4.6.1, or is sufficient to just leave it here?

[donmendelson]

@danjmarques ok to leave it here.