Subject: [bfcpbis] TBD issues #4 and #5: How to pick next sequence number

From: Tom Kristensen <[email-masked]>
Date: Tue, 13 Nov 2012 09:43:48 +0100

Issue with picking sequence numbers and making sure it doesn't cause any 
issues with (late) arriving retransmissions. This may happen, even 
though UDP/BFCP requires just one outstanding transaction at the time.

Gonzalo:
 > Section 6.2
[...]
 > The document says: " Transaction ID values are non-sequential and
 > entities are at liberty to select values at random."
 >
 > The document needs to make it clear what is the requirement and the
 > level of randomness required. For example, what happens if the same
 > transaction ID is reused and a retransmission of the message that
 > first used that transaction ID arrives?

Tom:
| No real random numbers are needed. This issue is solved in the
| upcoming version of the draft.
| However, we need a safe scheme to pick sequence numbers to avoid
| late arriving retransmissions cause confusion).

Gonzalo:
 > Section 8.1
 >
 > "The client MUST set the Transaction ID value in the common header to
 > a number that is different from 0 and that MUST NOT be reused in
 > another message from the client until a response from the server is
 > received for the transaction."
 >
 > See my comment above about reusing transaction ID values and the risk
 > of receiving retransmissions of the original message.

Tom:
| OK. This is kept from RFC 4582 using TCP (and no retransmissions). So, the
| idea should be to keep the RFC 4582 semantics for TCP transport and
| introduce some sort of "sliding window sequence number" reuse or simply
| add a sequential/wrapping sequence numbering for UDP as transport.

So, what do people think?

I feel the simplest here is to at least requring the BFCP entities to select
Transaction ID values in increasing order and a wrap around of the 16 
bit Transaction ID value. (This will require saying something about 
picking the intial value at random, not to close to wrapping and so on - 
I guess. Similar to RTP sequence numbers).

Or is it sufficient to mandate not reusing the X last Transaction IDs 
used by the BFCP entity?
Where X == what?

-- Tom

---

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 13 Nov 2012 10:55:22 +0200

Hi,

the text should explain the requirement (i.e., to avoid getting confused
with retransmissions that arrive late). With respect to the mechanism,
you can recommend (i.e., at SHOULD level) to use monotonically
increasing sequence numbers and let implementations choose any other
method that would meet the requirement as well.

Cheers,

Gonzalo