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,

This is a more complete answer on your DISCUSS

I think the description of the procedure was too much spread out in 
section 3. So, I propose to delete section 3.9, and change 3.4 to become:

--------------------------------------------------------------------------------------------

3.4.  Transmission interval

    A "text/red" or "text/t140" transmitter in a mixer SHALL send packets
    distributed in time as long as there is something (new or redundant
    T140blocks) to transmit.  The maximum transmission interval between
    text from the same source SHALL then be 330 ms, when no other
    limitations cause a longer interval to be temporarily used.
    It is RECOMMENDED to send the next packet to a
    receiver as soon as new text to that receiver is available, as long
    as the maximum character rate ("CPS") to the receiver is not exceeded
    during any 10-second interval.  The intention is to keep the latency
    low and network load limited while keeping good protection against
    text loss in bursty packet loss conditions.
    The main purpose of the 330 ms interval is for timing of redundant
    transmission, when no new text from the same source is available.

    The reason for the value 330 ms is that many sources of text will
    transmit new text with 300 ms intervals during periods of
    continuous user typing, and then reception in the mixer of such new
    text will cause a combined transmission of the new text and the
    unsent redundancy from the previous transmission. Only when the user
    stops typing, the 330 ms interval will be applied to send the
    redundancy.

    If the "CPS" value is reached, a longer transmission interval SHALL be
    applied for text from all sources as specified in [RFC 4103] and only
    as much of the text queued for transmission SHALL be sent at the end
    of each transmission interval that can be allowed without exceeding
    the "CPS" value. Division of text for partial transmission MUST
    then be made at T140block borders.
    When the transmission rate falls under the "CPS" value again,
    the transmission intervals SHALL be returned to 330 ms and
    transmission of new text SHALL return to be made as soon as new
    text is available.

    NOTE: that extending the transmission intervals during high load
    periods does not change the number of characters to be conveyed.
    It just evens out the load in time and reduces the number of packets
    per second. With human created conversational text, the sending
    user will eventually take a pause letting transmission catch up.

    See also Section 8

    For a transmitter not acting as a mixer, the transmission interval
    principles from [RFC4103] apply, and the normal transmission 
interval SHALL
    be 300 ms.

----------------------------------------------------------------------

Section 3.10 also needs a few changes, to read:

3.10.  Text placement in packets

    The mixer SHALL compose and transmit an RTP packet to a receiver when
    one of the following conditions has occurred:

    *  There is unsent text available for transmission to that receiver.

|   *  The current transmission interval ( normally 330 ms) has passed
|     since already transmitted text was queued for
|      transmission as redundant text.

    At the time of transmission, the mixer SHALL populate the RTP packet
    with all T140blocks queued for transmission originating from the
    source in turn for transmission as long as this is not in conflict
    with the allowed number of characters per second ("CPS") or the
    maximum packet size.  In this way, the latency of the latest received
    text is kept low even in moments of simultaneous transmission from
    many sources.

    Redundant text SHALL also be included, and the assessment of how much
    new text can be included within the maximum packet size MUST take
    into account that the redundancy has priority to be transmitted in
|   its entirety.  See Section 3.4

    The SSRC of the source SHALL be placed as the only member in the
    CSRC-list.

    Note: The CSRC-list in an RTP packet only includes the participant
    whose text is included in text blocks.  It is not the same as the
    total list of participants in a conference.  With audio and video
    media, the CSRC-list would often contain all participants who are not
    muted whereas text participants that don't type are completely silent
    and thus are not represented in RTP packet CSRC-lists.

.........................................................................................

The examples in section 3.21 needs some small adjustments:

in packet 104, the timer should be 20 800,

The text above and in packet 106 should be as you also discovered:

  B1 and B2 still need to be transmitted as redundancy.
|     This is planned 330 ms after packet 104. That
|    would be at 21130.

       |-----------------------|
|     |Seq no 106, Timer=21130|
       |CC=1                   |
       |CSRC list B            |
       | R2: B1, Offset=660    |
       | R1: B2, Offset=330    |
       | P:  Empty             |
       |-----------------------|

-----------------------------------------------------------------


Regards

Gunnar



.

Den 2021-05-19 kl. 23:25, skrev Gunnar Hellström:
> 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]