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

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

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]