Re: [MMUSIC] Starting shepherd's review of draft-ietf-mmusic-t140-usage-data-channel-07 - Bo's technical comments

[Bo Burman <[e-mail]>]

Yes

 

From: Christer Holmberg <christer.holmberg=[e-mail]> 
Sent: den 6 november 2019 17:30
To: Gunnar Hellström <[e-mail]>; Bo Burman <[e-mail]>; mmusic ([e-mail]) <[e-mail]>
Cc: '[e-mail]' <[e-mail]>
Subject: Re: [MMUSIC] Starting shepherd's review of draft-ietf-mmusic-t140-usage-data-channel-07 - Bo's technical comments

 

Bo, are you ok with the proposals?

 

Regards,

 

Christer

 

  _____  

From: Gunnar Hellström <[e-mail] <mailto:[e-mail]> >
Sent: Wednesday, November 6, 2019 5:16 PM
To: Christer Holmberg <[e-mail] <mailto:[e-mail]> >; Bo Burman <bo.burman=[e-mail] <mailto:bo.burman=[e-mail]> >; mmusic ([e-mail] <mailto:[e-mail]> ) <[e-mail] <mailto:[e-mail]> >
Cc: '[e-mail]' <[e-mail] <mailto:[e-mail]> >
Subject: SV: [MMUSIC] Starting shepherd's review of draft-ietf-mmusic-t140-usage-data-channel-07 - Bo's technical comments 

 

Christer,
I agree with your proposals.

Regards
Gunnar

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

  _____  

Från: Christer Holmberg <[e-mail] <mailto:[e-mail]> >
Skickat: den 6 november 2019 09:58:30
Till: Gunnar Hellström <[e-mail] <mailto:[e-mail]> >; Bo Burman <bo.burman=[e-mail] <mailto:bo.burman=[e-mail]> >; mmusic ([e-mail] <mailto:[e-mail]> ) <[e-mail] <mailto:[e-mail]> >
Kopia: '[e-mail]' <[e-mail] <mailto:[e-mail]> >
Ämne: Re: [MMUSIC] Starting shepherd's review of draft-ietf-mmusic-t140-usage-data-channel-07 - Bo's technical comments 

 

Hi,

 

--- 

3) In section 4.2.1, it says that “If the 'fmtp' attribute is not included, it indicates that no maximum character transmission rate is indicated.  It does not mean that the default value of 30 applies”; >why is this deviation from RFC 4103 chosen? Does it introduce a risk for interoperability problems with systems that also doesn’t use fmtp but interprets it as maximum 30 cps?

Gunnar?

[GH] I don't know why this deviation was chosen. But I have not commented it. You are right that it may introduce an increased risk for interoperability problems. But RFC 4103 has a precaution. In chapter 6, where the cps is introduced, it is said:
" 

   receivers of text/t140 MUST be designed so they can handle temporary
   reception of characters at a higher rate than this parameter
   specifies.  As a result malfunction due to buffer overflow is avoided
   for text conversation with human input."
 

(the reason for this note is for backward compatibility with RFC 2793, the obsoleted predecessor of RFC 4103, so it is not exactly our case, but still valid.) 

We have discussed the risk that implementations may not implement setting or reading the dcsa attributes because of the complexity to do so alongside with the WebRTC API. That situation may cause a situation where a sent cps parameter is not obeyed. So the case is quite similar to the case in RFC 4103, and applications would be required to prepare for handling temporary reception at high rates.

The intention of T.140 is to handle real-time text conversation between humans. Huge cut and paste chunks of text cannot be required to be handled rapidly. The highest speed human interaction would be with speech-to-text applications. A very rapid speaker may produce 200 words per minute. That is 17 characters per second. The speech-to-text applications often makes corrections by long backspaces and resendings. That may add 10 characters per second in the total. That results in a practical need of up to 27 characters per second for one stream. 

This calculation shows that for two-party calls, it would not hurt to use the same convention regarding cps default as RFC 4103 (30).

For centralized conference solutions with just one data channel from the conference server discussed in section 5.5, the need would be a multiple of that rate (27) corresponding to the number of simultaneous text senders. In well managed conferences this multiple is very close to one.   

The figures above are extremes. Currently most use of RTT is typing at maximum speeds of about 7 characters per second.

Leaving the default to unrestricted might attract some misuse by implementations or users trying to use the T.140 data channel for data transmission of data totally different from the intended real-time text. 

Conclusion after all this discussion: 

Neither leaving the default to unlimited, nor changing to a default of 30 cps as in RFC 4103 seems very critical. Any solution will do.

 

[Christer] I am pretty sure IESG would ask about this too, I suggest that we change the default to 30 cps.

 

---

​5) In section 5.5, in the note, it says ‘…with limitations in real-time performance and presentation style’; I think it would be helpful to briefly elaborate on what type of limitations would be >expected and why.

I think it is explained in the other text of the section. For example, using a single data channel without any protocol extensions would not allow to separate the sources etc.

[GH] I think we can offer a bit more text at the end of the note to clarify. How about this:

"T.140 shows two examples of presentation layout for real-time text, one being column oriented, with one column per participant, another being arranged in one column with labels identifying the beginning of text from each participant and text from a number of participants received and placed in places corresponding to these different participants. With a conference mixer using one text stream and not applying any presentation protocol extension would only be able to produce a string for presentation in one column, including a source label in the beginning of text from one participant and only show text in real time from one participant at a time, shifting real-time presented participant at suitable points in the text stream. (end of phrase, end of sentence, line separator, long delay etc.). This presentation style may not be preferred by the user and it may cause delay before presentation of text from other than the currently presenting participant."

Pew, maybe too long and detailed....

 

[Christer] Or, could we simply remove the last sentence ("Conference mixers that...")? The 1st paragraph already says why separate channels are needed, and the note says that future extensions may allow usage of a single channel, so I think it is pretty clear that using a single channel without any such extensions would come with limitations.

 

---
 

6) In section 6, bullet “If the gateway detects or suspects loss of data on the RTP stream…”; shouldn’t it await possible redundancy first and missing text marker is inserted only when the used >redundancy is not capable to repair the loss?

Gunnar?

[GH]The intention was that it would mean "after using possibly received redundant data".   You could interpret "loss of data" to mean that (instead of "loss of packets"), but let me try an improvement: "If the gateway detects or suspects loss of data on the RTP stream, after use of possibly received redundant data, …"

 

[Christer] What about?





"If the gateway detects or suspects loss of data on the RTP stream, and the lost data has not been retrieved using a redundancy mechanism, the gateway SHOULD insert the T.140 missing text marker [T140ad1] in the data sent on the outgoing T.140 data channel."

---
 

12) In section 11.1, in the [T140ad1] reference, is “aEUR” really part of the name? The name I find listed on the ITU-T web is “ITU-T T.140 (1998) Add. 1 (02/2000)”, and the title in the document >itself seems to be “Protocol for multimedia application text conversation; Addendum 1”.

Interesting. There is no "aEUR" in the XML file, so this seems to be something created by XML2RFC.
 
The intended title is: 
 
 Recommendation ITU-T.140 – Addendum 1  (02/2000), "Protocol for multimedia application text conversation"
 
I will fix it.

[GH] I chased a number of such occurrences earlier. I think it was because your editor inserted an unusual slanting quotation mark. Note that there is also a double quotation mark on the third line of the same reference. 

 

[Christer] I will double check.

 

---

 

Regards,

 

Christer