Re: [MMUSIC] FW: I-D Action: draft-schwarz-mmusic-t140-usage-data-channel-03.txt

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

Den 2016-09-12 kl. 15:00, skrev Schwarz, Albrecht (Nokia - DE):
>
> Hello Gunnar,
>
> like to reply on two aspects:
>
> 1) Which reliability mode?
>
> We had also the “reliable mode” in mind, understood that you are 
> indicating some follow up aspects which need to be specified.
>
Yes, let us draft it based on the "reliable mode".
That implies that if conditions are very bad, it can take 10 -30 seconds 
before any party get an indication that transmission failed.
That is not pleasant for a real-time conversational situation, but the 
conditions must be so bad that also the semi-reliable mode, breaking the 
transmission efforts of one T140 block of data after e.g. 4 seconds and 
trying with next T140 block would have similar risks to fail, so we 
would not gain much in conversational user experience by using 
"semi-reliable".
>
> 2) Event of “channel break” and option of “reconnection”
>
> Our understanding: such an event would be tight to the (temporary) 
> interruption of a lower layer connection oriented protocol, i.e., the 
> SCTP Association or the DTLS connection. Such a lower layer event 
> would impact ALL WebRTC data channels, i.e., wouldn’t be exclusive to 
> T140 data in our understanding.
>
Right. All subchannels of the association will break. My concern is the 
common application for a real-time multimedia call with e.g. audio, 
video and real-time text. If bad conditions make the data channels 
break, but the audio and video media sustain, we would require a 
function for reconnecting the real-time text connection and continue the 
text stream. And that would imply a risk for duplication or loss of 
data, because at the failure of the data channel, we can never be 
totally sure what had been transferred successfully. There are 
requirements to mark places where text might have been lost, and no 
duplicates are allowed, so in my view, we need to frame the transmitted 
text with a structure containing a sequence number and the T.140-text to 
transmit. And a requirement on the receiving side to check the sequence 
number in the reception and discard any duplications, but mark possible 
locations in the text stream where loss may have occured.


I realize that the specification should be independent on such higher 
level session specifications, but the framing and numbering and sequence 
checking needs to be done on the T140 transport level, so it is suitable 
to include these aspects in the draft.

Regards

Gunnar

>
> Any comments?
>
> Albrecht
>
> *From:*Gunnar Hellström [mailto:[e-mail]]
> *Sent:* Freitag, 2. September 2016 11:51
> *To:* Schwarz, Albrecht (Nokia - DE) <[e-mail]>; 
> [e-mail]
> *Subject:* Re: [MMUSIC] FW: I-D Action: 
> draft-schwarz-mmusic-t140-usage-data-channel-03.txt
>
> I see in this mail that the t140-usage-data-channel is on hold.
>
> I would like to open a discussion on topics not related to the reason 
> for the hold.
>
> I see that I am mentioned in two unresolved issues in the draft. It 
> would be good to resolve them. They are located in section 5.1.1.3, 
> sdp examples.
>
> "a=dcmap:1 label="text conversation";subprotocol="t140"; 
> ordered=true;max-time=???;max-retr=??? ; NOTE 1
>
> NOTE 1 - Maximum number of retransmissions = ??? (because FIXTHIS
>       <Gunnar>);
>                Maximum retransmission timing     = ??? (because FIXTHIS
>       <Gunnar>)."
>
>
> This issue relates back to discussions in RTCWEB about characteristics 
> in case of communication problems for the data subchannel used.
> The question is if we shall use the "reliable" mode of the data 
> channel or a "semi-reliable" mode with a maximum time for retries or a 
> maximum number of retries.
>
> It also requires a decision on what to recommend in case of such errors.
> If the channel breaks as it does when working in the "reliable" mode, 
> shall we then recommend a reconnection, with an effort to avoid 
> duplication and detect loss, or shall we recommend to break the whole 
> application session?
> If the channel sustains but reports error, as it does at least in some 
> cases for the errors in the "semi-reliable" modes, do we then have 
> sufficient information from the underlying protocol for the receiver 
> to avoid duplication and detect loss, or do we need to specify an 
> application level sequence numbering and check?
> T.140 requires transmission free of duplication.
> EN 301 549 requires marking in the text stream of possible places of 
> loss in case of transmission error.
>
> I would like to be able to recommend to use the reliable mode of the 
> data subchannel, because I expect it to be most commonly well 
> supported and best tested.
> The question is if it provides us with suitable characteristics.
>
> We need:
> Rapid transfer of small chunks of data at least three times per second.
> No duplication of data.
> Indication to the receiver of possible loss. ( or no loss ...)
> Small or no risk for stallling, waiting for result of retries when it 
> would instead be possible to transmit successfully. (very rare 
> occasional waiting of up to 10 seconds might be allowable (???) )
>
> Regards,
> Gunnar
>
> Den 2016-04-04 kl. 10:48, skrev Schwarz, Albrecht (Nokia - DE):
>
>     fyi, only keep-alive updates related DC candidate protocols No. 2 and 3 (T.140 & BFCP):
>
>     draft-schwarz-mmusic-t140-usage-data-channel-03.txt
>
>     draft-schwarz-mmusic-bfcp-usage-data-channel-02.txt
>
>     The technical work is currently suspended due to the dependency on "DC protocol No.1 'MSRP'":
>
>     draft-ietf-mmusic-data-channel-sdpneg
>
>     draft-ietf-mmusic-msrp-usage-data-channel
>
>     As you know there is currently a side discussion ongoing related the principle proceeding how the correspondent IANA registry should be architected.
>
>     (See agenda: 11:30-11:50 IANA Registry Structure for SDP Attributes (20 mins, Christian Groves & Paul Kyzivat)
>
>     Regards,
>
>     Albrecht
>
>     -----Original Message-----
>
>     From: I-D-Announce [mailto:[e-mail]] On Behalf Of [e-mail] <mailto:[e-mail]>
>
>     Sent: Montag, 4. April 2016 10:31
>
>     To:[e-mail] <mailto:[e-mail]>
>
>     Subject: I-D Action: draft-schwarz-mmusic-t140-usage-data-channel-03.txt
>
>     A New Internet-Draft is available from the on-line Internet-Drafts directories.
>
>              Title           : T.140 Text Conversation over Data Channels
>
>              Authors         : Keith Drage
>
>                                Juergen Stoetzer-Bradler
>
>                                Albrecht Schwarz
>
>         Filename        : draft-schwarz-mmusic-t140-usage-data-channel-03.txt
>
>         Pages           : 19
>
>         Date            : 2016-04-04
>
>     Abstract:
>
>         This document specifies how the ITU-T Protocol for multimedia
>
>         application text conversation (Recommendation ITU-T T.140) can be
>
>         instantiated as a data channel sub-protocol, using the SDP
>
>         offer/answer exchange-based external negotiation defined in [I-
>
>         D.ietf-mmusic-data-channel-sdpneg]. Two network configurations are
>
>         documented: a WebRTC end-to-end configuration (connecting two T.140
>
>         over data channel endpoints), and a gateway configuration
>
>         (connecting an T.140 over data channel endpoint with an T.140 over
>
>         RTP/UDP endpoint).
>
>     The IETF datatracker status page for this draft is:
>
>     https://datatracker.ietf.org/doc/draft-schwarz-mmusic-t140-usage-data-channel/
>
>     There's also a htmlized version available at:
>
>     https://tools.ietf.org/html/draft-schwarz-mmusic-t140-usage-data-channel-03
>
>     A diff from the previous version is available at:
>
>     https://www.ietf.org/rfcdiff?url2=draft-schwarz-mmusic-t140-usage-data-channel-03
>
>     Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.
>
>     Internet-Drafts are also available by anonymous FTP at:
>
>     ftp://ftp.ietf.org/internet-drafts/
>
>     _______________________________________________
>
>     I-D-Announce mailing list
>
>     [e-mail] <mailto:[e-mail]>
>
>     https://www.ietf.org/mailman/listinfo/i-d-announce
>
>     Internet-Draft directories:http://www.ietf.org/shadow.html  orftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>     _______________________________________________
>
>     mmusic mailing list
>
>     [e-mail] <mailto:[e-mail]>
>
>     https://www.ietf.org/mailman/listinfo/mmusic
>
>
>
> -- 
> -----------------------------------------
> Gunnar Hellström
> Omnitor
> [e-mail] <mailto:[e-mail]>

-- 
-----------------------------------------
Gunnar Hellström
Omnitor
[e-mail]
[phone]