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

From: Christer Holmberg <[email-masked]>
Date: Sun, 5 Apr 2020 18:57:46 +0000

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

---

From: Martin Duke <[email-masked]>
Date: Sun, 5 Apr 2020 16:54:32 -0700

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.'

On Sun, Apr 5, 2020 at 11:57 AM Christer Holmberg <
[email-masked]> wrote:

> We did sort out everything, and the outcome of the review is implemented
> in the current version (-12) of the draft.
>

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 6 Apr 2020 07:57:06 +0000

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.

Regards,

Christer

On Sun, Apr 5, 2020 at 11:57 AM Christer Holmberg <mailto:[email-masked]> wrote:
Hi Martin,

Regards,

Christer

---

From: Gunnar Hellström <[email-masked]>
Date: Mon, 6 Apr 2020 11:58:47 +0200

Please see resolution proposal below

> 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

> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

-- 

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

Gunnar Hellström
Omnitor
[email-masked]
+46 708 204 288

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 6 Apr 2020 10:05:09 +0000

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" <[email-masked]> wrote:

    

    

    
    ----------------After change--------------------------------------

    
    Regards
    
    Gunnar

    -- 

    Gunnar Hellström
    Omnitor

---

From: Martin Duke <[email-masked]>
Date: Mon, 6 Apr 2020 21:50:18 -0700

This suggestion is fine with me.

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

>     >> 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
>     > 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.
>
>     > We did sort out everything, and the outcome of the review is
> implemented in the current version (-12) of the draft.
>     >

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 7 Apr 2020 06:54:18 +0000

Thanks! :)

Regards,

Christer

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

On Mon, Apr 6, 2020 at 3:05 AM Christer Holmberg <[email-masked]<mailto:[email-masked]>> 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" <[email-masked]<mailto:[email-masked]>> wrote:

    ----------------After change--------------------------------------

    Regards

    Gunnar

    >
    > Regards,
    >
    > Christer
    >
    >
    > On Sun, Apr 5, 2020 at 11:57 AM Christer Holmberg <mailto:[email-masked]<mailto:[email-masked]>> wrote:
    > Hi Martin,
    >
    > [email-masked]<mailto:[email-masked]>

    --

    Gunnar Hellström
    Omnitor
    [email-masked]<mailto:[email-masked]>
    +46 708 204 288