Re: [AVTCORE] Benjamin Kaduk's Discuss on draft-ietf-avtcore-multi-party-rtt-mix-18: Answer 4.

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

Hi Ben,

Thank you for the kind words.

The inserted words about packets out-of-order that you did not find in 
version -19 are there, but in the beginning of section 3.16.2, instead 
of in 3.16.3 where you expected to find them.

Please see furthe comments inline.

Den 2021-05-26 kl. 02:23, skrev Benjamin Kaduk:
> Hi Gunnar,
>
> On Tue, May 25, 2021 at 12:29:51PM +0200, Gunnar Hellström wrote:
>> Benjamin,
>>
>> Continuing the answers with the last part.,
> Thank you for going through them all.  To be clear, I was not waiting for
> you to finish before I started replying -- I just had a deadline earlier
> today and did not have a chance to do much with my email sooner.  Having
> the content chunked up into multiple pieces can make it easier to manage.
>
> This is the only message I'm going to respond to, though, since I basically
> have nothing further to say.  (I've already updated my ballot position to
> remove the Discuss.)  I'm really impressed with how you took my comments
> and turned them into improved text in the document, especially in the
> places where I did not have a clear proposal.  I also appreciate your
> explanations in the places where my questions did not make sense or are
> already covered by some of the fundamental documents in this space; the
> gaps in my knowledge are slowly getting filled in.
>
>> Den 2021-05-19 kl. 04:53, skrev Benjamin Kaduk via Datatracker:
> [...]
>> [GH]Again, thanks for a thorough review and many good proposals for changes.
> I must thank you again for your thorough responses; I feel like I am not
> doing them justice by only sending this one short note, but do not want to
> make you read through a repetitive set of "yes", "this sounds good", "thank
> you", etc.
>
> I read through the changes in the already-uploaded -19 (thank you again!),
> and there were only two items that might be worth following up on (both in
> section 3.16.3 of the -19):
>
> You had proposed:
>
> [GH] Would it be sufficient to insert the words "and reordering" in the
> first two sentences in the paragraph to read: "The receiver SHALL monitor
> the RTP sequence numbers of the received packets for gaps and packets
> out of order.  If a sequence number gap appears and still exists after some
> defined short time for jitter and reordering resolution, the packets in the
> gap SHALL be regarded as lost."
>
> I don't think this made it into the -19; my preference is to use your
> proposed text that includes mention of reordering, but I do not insist on
> it.

[GH] They are there, in 3.16.2, where basic packet reception and gap 
analysis is specified.

it says:

"   The receiver SHALL monitor the RTP sequence numbers of the received
    packets for gaps and packets out of order.  If a sequence number gap
    appears and still exists after some defined short time for jitter and
    reordering resolution, the packets in the gap SHALL be regarded as
    lost. "

This is intended to require that packets are in order when they go to 
the loss analysis and data retrieval stages.

Very late packets out-of-order would be regarded lost. When you said 
that you could imagine cases of duplication, did you then imagine a 
procedure which would recover text also from late coming packets after 
the short time mentioned in the paragraph above? It would be possible, 
but I do not think it should be part of the general document, because it 
would possibly mean manipulating display buffers already presenting 
earlier received text.

I have created a paragraph for that, that can follow the first in 
3.16.2, but I do not think it adds any value to insert it. What do you 
think?

"   Advanced procedures for recovering data from packets received out of
    order later than the short time for jitter and reordering resolution
    mentioned above MAY be implemented but are out of scope for this 
document.
    Such procedures would need to manipulate data in receive buffers and
    possibly also in presentation areas. The procedures MUST avoid
    duplication of already received data."

>
> There was also a mention about the procedures for extracing T140blocks with
> the redundancy procedure, where we currently say "T140blocks SHALL be
> extracted in the following way.  The description is adapted to the default
> redundancy case using the original and two redundant generations."  While I
> am inclined to agree that the extension to the generic case with other
> levels of redundancy is something that the reader can be expected to
> perform, it feels a little incomplete to say that something "SHALL be
> [done] in the following way" but give a not-complete/not-generic procedure.
> Only for that reason do I prefer to have an explicit indication that the
> procedure might need to be adjusted for a different level of redundancy; as
> for the previous point, I do not insist on any change, though.

[GH] I have made a try to generalize the description. I think it can 
replace the current limited one. What do you think?

"
3.16.3.  Extracting text and handling recovery

    When applying the following procedures, the effects MUST be
    considered of possible timestamp wrap around and the RTP session
    possibly changing SSRC.

    When a packet is received in an RTP session using the packetization
    for multiparty-aware endpoints, its T140blocks SHALL be extracted in
    the following way.

    The source SHALL be extracted from the CSRC-list if available,
    otherwise from the SSRC.

    If the received packet is the first packet received from the source,
    then all T140blocks in the packet SHALL be retrieved and assigned to
    a receive buffer for the source beginning with the oldest available
   redundant generation,  continuing with the younger redundant generations
   in age order and finally the primary.

    NOTE: The normal case is that in the first packet, only the primary
    data has contents.  The redundant data has contents in the first
    received packet from a source only after initial packet loss.

    If the packet is not the first packet from a source, then if redundant
    data is available, the process SHALL start with the oldest generation.
    The timestamp of that redundant data SHALL be
    created by subtracting its timestamp offset from the RTP timestamp.
    If the resulting timestamp is later than the latest retrieved data
    from the same source, then the redundant data SHALL be retrieved and
    appended to the receive buffer.  The process SHALL be continued in
    the same way for all younger generations of redundant data. After that,
    the timestamp of the packet SHALL be compared with the timestamp of
    the latest retrieved data from the same source and if it is later,
    then the primary data SHALL be retrieved from the packet and appended
    to the receive buffer for the source.

"

Regards

Gunnar

>
> Thanks again,
>
> Ben

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