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

[Tom Kristensen <[e-mail]>]

In order not to duplicate the normative description on how to pick 
Transaction ID values for unreliable transport, I move the text from 6.2 
to Section 8 where the BFCP transaction semantics are defined.

New section 8 enclosed.

-- Tom

On 11/13/2012 09:55 AM, Gonzalo Camarillo wrote:
> 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
>>      
>