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

[Christer Holmberg <[e-mail]>]

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]