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]” to “[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]
[phone]