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

[James Hamlin <[e-mail]>]

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



[X]


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 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



[X][X]

[X]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.