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

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

Hi Christer, Bo and all,

Please see my answers and comments inline,


Den 2019-11-05 kl. 14:30, skrev Christer Holmberg:

Hi Bo,

Thank You for the review! I will reply inline. In some cases I will refer the question to Gunnar.



1) In section 1, note 1, with “WebRTC term”, do you mean that “T.140 data channel” is introduced in WebRTC specifications? Or should it be “This T.140 data channel term in WebRTC context…”? >If not, in what way is it a “WebRTC term”, which I interpret as something belonging to or being originated from WebRTC?

2) In the same note 1, suggest to change “actually synonym to” to “technically equivalent to” or “technically similar to”. If you think
that would not be appropriate, please elaborate on in what way it is synonym.



ITU-T T.140 talks about a "data channel", but my understanding is that it also covers e.g., RTP transport of T.140.

I suggest to remove the note, because I think it could cause confusion.

[GH] I agree, the note is not important, but just a good link between the general presentation level of ITU-T T.140 with its expressed need for a transport method, and the transport method provided by the new specified T.140 data channel.



---



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.





---



4) In section 4.2.3.1.1, for the ‘inactive’ case, it is unclear to me in which cases a t140 data channel would be opened but not used. Why open the channel in the first place when a new SDP O/A is >anyway needed to change ‘inactive’ to something else? I’m however OK to keep it for completeness and it shouldn’t do any harm if kept, but a clarification would be helpful.



One may want to create a data channel for later use, and/or perhaps some pre-condition mechanism is used where bearers etc need to be established before text can be sent.

I don't think we normally clarify usage of 'inactive' in for other media types either.

[GH] I agree. Also, since 4.2.3.2 Modify Text Direction is short, referencing back to 4.2.3.1.1 and 4.2.3.1.2, I think 4.2.3.1.1 should contain 'inactive'.



---



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




---



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, …"





---



7) In section 6, bullet “If the gateway detects that the T.140 data channel has failed”; what about if the RTP stream has failed and was reestablished? Shouldn’t missing text markers be inserted >by the gateway then too?



Gunnar?

[GH] Good point, but that case may be thought of as included in point 6 above. It is much more important to have the points about the failure of the T.140 data channel clearly pointed out, because I am afraid that there is a common misconception that reliable WebRTC channels are reliable and always deliver data.



---



8) In section 7, you mention “subprotocol”; do you mean the “dcmap” line subprotocol parameter?



Yes.

If you want, I could add the following sentence:

"The subprotocol is indicated using the SDP 'dcmap' attribute."

---



9) In section 7, the “…MUST specify the modality for that subprotocol…” seems like a general update to 8374 that is not specific or exclusive to T.140? I’m not convinced making such statement is >within the scope of this document.



The Section defines a general update to RFC 8373. It is not exclusive to T.140.

Yes, it's done within the t140-data-channel draft, but I don't think we would need a separate draft just for that update.

---



10) In section 8, you reference draft-ietf-rtcweb-data-channel and draft-ietf-mmusic-data-channel-sdpneg; are there any additional T.140-specific considerations, e.g. related to T.140 use of ->sdpneg? If not, it could be helpful to say so.



Regarding data channels (1st paragraph), there is a sentence saying: "As data channels are always encrypted by design, the T.140 data channels will also be encrypted.".

Regarding sdpneg (2nd paragraph), I could add: "There are no additional T.140 data channel specific security considerations."

---



11) In section 9.2, 9.3, and 9.4, please change all occurrences of “MMUSIC Chairs” to “IESG” and “[e-mail]<mailto:[e-mail]>” to “[e-mail]<mailto:[e-mail]>”, since IESG is expected to persist longer than any >individual WG.



Will fix as suggested.

---



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.




---

I will address the editorial comments/nits in a seprate reply.

Regards,

Christer



Regards

Gunnar




--

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

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