Re: [AVTCORE] New Version Notification for draft-ietf-avtcore-multi-party-rtt-mix-09.txt

[Gunnar Hellström <[e-mail]>]

James,

Thanks for your thorough analysis.

You are right as you say last that I am changing the mixing method 
inspired by Brian's question why we needed to complete transmission of 
all redundant generation of text from one source before switching source.

With the new method, every sent packet can have a different source in 
CSRC. The recovery mechanism is based on checking the timestamp of the 
redundancy in a packet to the timestamp of the latest received text from 
the same source. If the redundant text is later, then there was loss, 
and the redundancy should be used to recover the loss.

There will be a need to check if there was any unrecoverable loss. That 
check will need to be different with this new mixing method. I will 
check to see if your thoughts can be applied.

The performance is much better than with version -09. For most 
conferences, the mixer will cause between 0 and 100 ms delay of text, 
which is good regarding that users start getting annoyed not until text 
is delayed more than 1 second after it is typed (or otherwise entered).

The new version will be submitted after the IETF meeting next week.

Regards

Gunnar

Den 2020-11-12 kl. 16:20, skrev Paul Kyzivat:
> James,
>
> Comment toward the end...
>
> On 11/12/20 7:05 AM, James Hamlin wrote:
>> Hi Gunnar
>>
>>
>> I had another look at the recovery text at the end of section 3.23. I 
>> think the statement
>>
>> "If CSRC is different before and after the gap, a gap of 4 can be 
>> recovered if the last packet before the gap contained only R2 data" 
>> is should read:
>>
>> "If the CSRC is different before and after the gap, a gap of 4 can be 
>> recovered if the last packet before the gap contained primary data 
>> and the newly received packet contains R2 data".
>>
>> I also think the condition for a 'third' CSRC to have been active in 
>> the missing packets is more complicated than stated.
>>
>>
>> To avoid the document getting too complicated, it might be better 
>> just to say that receivers should put in a missing text mark against 
>> the mixer unless they have implemented an algorithm that 
>> determines that loss is limited to a smaller group of participants.
>>
>>
>> I think the diagram below might help to visualize the conditions 
>> where it is possible determine from sequence numbers, where loss has 
>> occurred. WARNING: it's upside down with primary at the top and I've 
>> used the word "step" instead of "gap" and then used "gap" to refer to 
>> the gap that determines whether a 'third' party CSRC could have 
>> been active in the missing packets. I've deliberately used more than 
>> 3 redundant generations as RFC4103 doesn't set a limit. Colored 
>> blocks represent data and white an empty or undetermined block.
>>
>>
>> A receiver has a newly received packet and a previously 
>> received packet, with a lower sequence number.
>>
>> From the newly received packet one can draw a 
>> square showing the packets that are known to have been from 
>> the second participant (in this case the blue participant). The green 
>> arrows show data that can be recovered and 
>> the yellow show that the two empty redundant 
>> generations show where primary blocks must have been empty.
>>
>>  From the previously received packet one can draw a square (in this 
>> case for the red participant), showing the packets that must have 
>> been for that participant, to run out remaining redundant generations.
>>
>>
>> Then, to work out if anything was lost, by any participant, try to 
>> draw test squares with primary data in the top left, which reach to 
>> the bottom of the diagram. It is only possible for something to be 
>> lost, if such a square can be drawn that doesn't overlap a square 
>> with a different participant's color.
>>
>>
>> So, in the diagram, one couldn't draw a 5*5 square in orange without 
>> overlapping the blue or red so there was definitely no text from 
>> anyone other than blue and red.
>>
>> It is possible to draw red 5*5 squares starting in the 
>> first, or second lost packets, without overlapping the blue and so it 
>> is possible that there was unrecoverable loss of the red 
>> participant's text. It is also possible to draw a blue square 
>> starting at 4th missing packet, without overlapping the red square so 
>> it is possible that there was unrecoverable loss of the 
>> blue participant's text. It is also possible that 
>> there were keep-alive packets meaning that nothing was lost. It is 
>> also possible to draw a blue square starting at the fifth missing 
>> packet but we know that primary was empty (follow the yellow arrow).
>>
>>
>>
>> Using this mechanism, I think the algorithm for determining packet 
>> loss markers is:-
>>
>>
>> let step = the difference in the start and end sequence numbers + 1; 
>> // When no packets are missing step == 2
>> let n_gen = number of generations including primary
>> let block   = depth to last non-empty redundant block in the newly 
>> received packet;
>> let p_block = n_gen - depth to first non-empty redundant block in the 
>> previously most recently received packet;
>> let gap = step - block - p_block;
>>
>>
>> if (gap >= n_gen) then
>>
>>      Insert a missing text marker against the mixer;      // missing 
>> text could have been from anyone
>>
>> else
>>
>>      if (change in participant) then //  CSRC is different before and 
>> after the missing packets
>>
>>          if (step - p_block > n_gen) then
>>
>>              Insert a missing text marker against the second 
>> participant;
>>
>>          endif
>>
>>
>>          if (step - block > n_gen) then
>>
>>              Insert a missing marker against the first participant;
>>
>>          endif;
>>
>>
>>      elseif (step >= n_gen) then
>>
>>              insert a missing marker against the participant;
>>
>>      endif
>>
>> endif
>>
>> As said above, it probably makes sense to keep this detail out of the 
>> document and err on the side of caution by encouraging 
>> implementers to mark text missing against the mixer.
>
> I agree that such detail could make the document difficult to follow. 
> Yet it seems helpful.
>
> You might consider putting it in a non-normative annex - as a hint 
> about how a developer might approach this problem.
>
>     Thanks,
>     Paul
>
>> I see from previous mails that you are looking at using timestamps to 
>> assist recovery; I haven't considered that in the above. 
>> Apologies for bringing this analysis a bit late in the day; and I 
>> may have made mistakes - happy to be corrected.
>>
>>
>> Best regards
>>
>>
>> James
>>
>>
>>
>> James Hamlin
>> Contractor
>> Purple, a Division of ZP Better Together, LLC
>> purplevrs.com
>>
>> The information contained in this e-mail message is intended only for 
>> the personal and confidential use of the recipient(s) named above. If 
>> you have received this communication in error, please notify us 
>> immediately by e-mail, and delete the original message.
>>
>>
>> _______________________________________________
>> Audio/Video Transport Core Maintenance
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/avt
>>
>
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [e-mail]
> https://www.ietf.org/mailman/listinfo/avt

-- 
Gunnar Hellström
GHAccess
[e-mail]