Re: Spin bit - semantics - rtt and loss

[<[e-mail]>]

Hi Mikkel,

One thing about patterned sequences as opposed to square, is their lack of 
robustness to mild loss or reordering. That's unfortunate, because passive 
measurement is primarily useful when such things occur ...

To me the bottom line is that properly addressing this need has a cost, and that 
this cost may exceed one single bit (above the 1 or 2 spin bit(s)).

The alternative then becomes

  (a) let's handle packet loss ; need k bits ; that may not fit in the currently 
"available" bits in the type byte ; let's frankly allocate them

  (b) packet loss handling deemed luxury


On 23/03/2018 08:50, Mikkel Fahnøe Jørgensen wrote:
> It should be noted that a Gray counter would not count linearly, but have one 
> bit changing for every power of 2 larger amount of data sent (details may vary).
>
> The spin bit could also be encoded by some phase of the pattern, for example 
> sending the same 8 bit count twice, but with one of the counts inverted when 
> spin is set. But that makes things more difficult to implement and looses some 
> precision when very few packets are sent.
>
> Kind Regards,
> Mikkel Fahnøe Jørgensen
>
>
> On 23 March 2018 at 08.42.28, Mikkel Fahnøe Jørgensen ([e-mail] 
> <mailto:[e-mail]>) wrote:
>
>> Just to summarize the square wave discussion:
>>
>> It is possible to send many other patterns one bit at a time that deal with 
>> both short and long range loss.
>> At some point I suggested emitting a 8 bit Gray code counter which is emitted 
>> one bit at a time. Optionally repeated twice before changing in order to 
>> better sync the signal. This repeats every 8 packets or every 16 packets.
>>
>> It was designed for loss detection - not spin or RTT because that isn't 
>> encoded into signal. But it can be used to sync the instance of a separate 
>> spin bit. This would use two bits.
>>
>> Kind Regards,
>> Mikkel Fahnøe Jørgensen
>>
>>
>> On 23 March 2018 at 01.13.01, Lubashev, Igor 
>> (ilubashe=[e-mail] 
>> <mailto:ilubashe=[e-mail]>) wrote:
>>
>>> Since we decided to put some work into spin bit, albeit in a separate 
>>> document from V1, here are some thoughts.
>>>
>>> It is nice that spin bit can be used to estimate rtt. I am sure that it is 
>>> useful to many well-meaning people. It is not very useful to me, though.
>>>
>>> When I debug network problems, they are much more likely to be about lost 
>>> packets. And I like to be able to know packet loss frequency and pattern 
>>> very accurately. (I am assuming an encrypted packet number, or the problem 
>>> would be trivial.)
>>>
>>> I would prefer, if we have a spin bit, for it to spin not every rtt but 
>>> every, say, 10 packets that an endpoint sends. Client sends 10 packets with 
>>> 0 and then 10 packets with 1, repeat. Sever does the same.
>>>
>>> So maybe two spin bits -- one for rtt and one for loss? I would assume that 
>>> loss bit would assist in rtt estimation in case of loss.
>>>
>>> Thoughts?
>>>
>>> - Igor


_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.