Re: [AVTCORE] Benjamin Kaduk's Discuss on draft-ietf-avtcore-multi-party-rtt-mix-18: (with DISCUSS and COMMENT)

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

Benjamin,

Thanks for the thorough review.

I will respond in multiple pieces, starting with the first parts of the 
DISCUSS.

Den 2021-05-19 kl. 04:53, skrev Benjamin Kaduk via Datatracker:
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-avtcore-multi-party-rtt-mix-18: Discuss
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-avtcore-multi-party-rtt-mix/
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> I'm not sure I understand how the examples are consistent with the main
> specification, so let's please discuss it to either un-confuse me or fix
> the document.
>
> Section 3.9 seems to say that the oldest (source or redundant) text at
> the mixer takes priority when there is text from more than one source
> waiting to be sent, but the examples in Section 3.21 seem to show (e.g.)
> text received from A at time 20400 that is to be sent as redundancy,
> being sent after text from B received at time 20500 (sent as primary).
> Is the intent that if there is any primary text, the oldest primary text
> is sent first, and only if there is no outstanding primary text do we
> consider the redundant text?

[GH] You are right. The text in 3.9 i not clear enough. If there is no 
new text from A, the redundancy of A shall not be sent until 330 ms 
after the primary text from A was sent.

Only if new text arrives from A before 330 ms after the previous text 
was sent, then both that new text and the redundancy shall be sent, when 
the new text is the oldest available.

So in the example, it is correct to send text from B first.

One way to say it is that redundant text shall not participate in the 
age assessment until it is 330 ms older than when it was last sent. But 
it shall be included if new text is available and decided to be sent.

When composing suitable text from this, we also need to consider that 
the "CPS" value may puts a limit to how much new text may be sent.

We also have the following words last in 3.12:

"   The T140blocks saved for transmission as redundant data are assigned
    a planned transmission time 330 ms after the current time, but SHOULD
    be transmitted earlier if new text for the same source gets in turn
    for transmission before that time."


So, 3.9 is about interleaving new text and not about making sure that 
redundancy is sent even when there is no new text.  The text in 3.9 may 
become correct by deleting the redundancy from the age assessment, and 
include "CPS" consideration, to result in:

"The source with the oldest text received in the mixer  SHALL be next in 
turn to get all its available unsent text transmitted, as long as it is 
allowed considering the "CPS" value of the receiver.  Any redundant 
repetitions of earlier transmitted  text not yet sent the intended 
number of times SHALL be included as redundant retransmission in the 
transmission."



>
> In a related vein, Section 3.10 says that a packet is sent when (among
> other things) "330 ms has passed since already transmitted text was
> queued for transmission as redundant text".  But that doesn't say
> anything about the timer being reset by subsequent transmission or
> queuing of redundant text, so I'm not sure how in the Section 3.21
> example, we say that transmitting B1 and B2 as redundancy was planned as
> 330 ms after packet 105 -- the original B2 was sent in packet 104, so
> shouldn't the 330ms start from packet 104's transmission?  (The stated
> time for this seems to match 330ms after 104, so maybe the "105" is just
> a typo?)
>
>
> I also left a note in the comment that there's a remark about "lower
> security level" in Section 3.19 that's not really accurate; we should
> resolve that in some manner before the document proceeds.
>
>
[GH]

-Answers to be continued,

Gunnar
>
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [e-mail]
> https://www.ietf.org/mailman/listinfo/avt

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