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

[Gonzalo Camarillo <[e-mail]>]

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

On 13/11/2012 10:43 AM, Tom Kristensen wrote:
> 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