Re: [MMUSIC] Martin Duke's Discuss on draft-ietf-mmusic-t140-usage-data-channel-12: the COMMENT

[Martin Duke <[e-mail]>]

This suggestion is fine with me.

On Mon, Apr 6, 2020 at 3:05 AM Christer Holmberg <
[e-mail]> wrote:

> Gunnar's suggestion looks good to me. Then the need to interpret "strong
> indication" goes away.
>
> Regards,
>
> Christer
>
>
>
> On 06/04/2020, 12.59, "Gunnar Hellström" <[e-mail]>
> wrote:
>
>     Please see resolution proposal below
>
>     Den 2020-04-06 kl. 09:57, skrev Christer Holmberg:
>     > Hi,
>     >
>     >> In Section 5.4, the endpoint "MUST NOT retransmit T140blocks" and
> "MUST NOT insert missing text markers" unless "it has strong
>     >> indications that a T140block has been lost." The criterion is vague
> so I'm not sure how the MUST is enforceable. I don't have an alternate
>     >> proposal so I'll just ask if there's a way to be more specific
> about 'strong indications.'
>     > Unfortunately there isn't, as there is no T.140 level
> acknowledgement of what has been delivered to the peer in the case of
> network failure or congestion.
>     >
>     > Even if the application keeps track of the SCTP TSN
> acknowledgements, that may also be lost in case of network failure or
> congestion.
>     >
>     > But, perhaps we could describe the lack of TSN acknowledgement as a
> strong indication, but point out that it is still not 100% waterproof.
>
>     It is likely that a channel tear down because of transmission problems
>     is much more rare than a multiple packet loss situation that causes
>     insertion of the loss mark for RTP based transmission of real-time
> text.
>
>     The situation can probably be viewed as similar to when a conference
>     system gets occasional problems with the connection and indicates that
>     on the user screen with a message "there is occasional problems with
>     your Internet connection, trying to reconnect....".
>
>     So we could reduce the ambition to handle this situation perfectly.
>     Also, note that there are situations in RTP based transmission of
>     Real-time text where we just suspect that some text might have been
>     lost, and we insert the loss mark. It should be regarded to be a "mark
>     of possible loss".
>
>     How about this wording of part of 5.4
>
>
> -----------------------Original---------------------------------------------
>
>         As a T.140 data channel does not provide a mechanism for
>         the receiver to identify retransmitted T140blocks after channel
>         reestablishment, the sending endpoint MUST NOT retransmit
> T140blocks
>         unless it has strong indications that a T140block has been lost
>         during the data channel failure.  Similarly, as a T.140 data
> channel
>         does not provide a mechanism for a receiver to detect lost
> T140blocks
>         during channel reestablishment, it MUST NOT insert missing text
>         markers [T140ad1] unless it has reasons to suspect that a T140block
>         might have been lost.  Different mechanisms used by sending and
>         receiving endpoints to detect or suspect text loss are outside the
>         scope of this specification.
>
>     ----------------After change--------------------------------------
>
>        As a T.140 data channel does not provide a mechanism for
>         the receiver to identify retransmitted T140blocks after channel
>         reestablishment, the sending endpoint MUST NOT retransmit
> T140blocks.
>        Similarly,  a receiver SHOULD indicate to the user that there has
>     been a channel reestablishment,
>        and that text might have been lost. This MAY be done by inserting
> the
>     missing text
>         markers [T140ad1] or in any other way evident to the user.
>
>     -__________________________________________
>
>     Regards
>
>     Gunnar
>
>     >
>     > Regards,
>     >
>     > Christer
>     >
>     >
>     > On Sun, Apr 5, 2020 at 11:57 AM Christer Holmberg <mailto:
> [e-mail]> wrote:
>     > Hi Martin,
>     >
>     > Thank You for the review and comments!
>     >
>     > In this reply I try to address your COMMENT. I will provide my input
> on the DISCUSS in another repaly.
>     >
>     >
> ----------------------------------------------------------------------
>     > COMMENT:
>     >
> ----------------------------------------------------------------------
>     >
>     >>      The Tsvarea review cites a few other places where the 2119
> language is a little
>     >>      loose, e.g. MUSTs with vague and unenforceable criteria.
>     > We did sort out everything, and the outcome of the review is
> implemented in the current version (-12) of the draft.
>     >
>     > Is there something specific you still needs to be addressed?
>     >
>     > Regards,
>     >
>     > Christer
>     >
>     >
>     >
>     >
>     >
>     >
>     > _______________________________________________
>     > mmusic mailing list
>     > [e-mail]
>     > https://www.ietf.org/mailman/listinfo/mmusic
>
>     --
>
>     + + + + + + + + + + + + + +
>
>     Gunnar Hellström
>     Omnitor
>     [e-mail]
>     [phone]
>
>
>
>