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

[Christer Holmberg <[e-mail]>]

Thanks! :)

Regards,

Christer

From: Martin Duke <[e-mail]>
Date: Tuesday, 7 April 2020 at 7.50
To: Christer Holmberg <[e-mail]>
Cc: Christer Holmberg <christer.holmberg=[e-mail]>, Flemming Andreasen <[e-mail]>, Gunnar Hellstrom <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: [MMUSIC] Martin Duke's Discuss on draft-ietf-mmusic-t140-usage-data-channel-12: the COMMENT

This suggestion is fine with me.

On Mon, Apr 6, 2020 at 3:05 AM Christer Holmberg <[e-mail]<mailto:[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]<mailto:[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]<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]<mailto:[e-mail]>
    > https://www.ietf.org/mailman/listinfo/mmusic

    --

    + + + + + + + + + + + + + +

    Gunnar Hellström
    Omnitor
    [e-mail]<mailto:[e-mail]>
    [phone]