Hi, I am fine with all Christer's conclusions and proposals below. Gunnar Den 2020-02-02 kl. 17:51, skrev Christer Holmberg: > Hi, > > --- > > 1/ > > ... > > > >>>>>> In any case, I don't think this is a real-life problem - in cases where T.140 > > >> is > > >>>>>> used as intended. As Gunner mentioned, T.140 is not designed or intended > > >> for > > >>>>>> transport of large amount of copy-pasted text but for human interactions. > > >>>>> Then probably a big warning sign should be added to the document. > > >>>>> > > >>>> We do reference T.140, and I assume the scope and usage are described > > >> there. RFC 4103 does not have such statement either. > > >>>> But, sure, if people think it is useful we can add a note saying that T.140 is > > >> intended for real-time interaction, not for transfer of text files, documents etc. > > >>> [GH] RFC 4103, has the following wording in its introduction: > > >>> > > >>> "The text is intended to be entered by human users from a keyboard, > > >>> handwriting recognition, voice recognition or any other input method. > > >>> The rate of character entry is usually at a level of a few characters > > >>> per second or less." > > >>> > > >>> I suggest that the first sentence is added to our introduction. > > >> [CH] I suggest adding both sentences. > > > > > > Regarding the congestion control impact, both sentences provide useful information. With the second sentence it is easier to understand > > > how low the data rate will be (and that it will not cause much issues in many parts of the Internet). > > > > > > [GH] Yes, possible. I hesitated to propose adding both because of the > > > expression "a few", considering that with speech-to-text and a rapid > > > speaker, text production can reach about 20 CPS. But the sentence says > > > "usually", so I can accept that both are added. > > > > Good. > > > > So, the current suggestion for addressing the issue: add the RFC 4103 sentence (see above) to the draft. > > No change to suggestion above. > > ----- > > 2/ > > ... > > > >> > > >> [CH] Just to keep everyone in sync, the current proposal is to add some text > > >> like: > > >> > > >> "If the receiver receives text at a higher rate than it can handle, > > >> e.g., > > >> because the sender does not support the cps parameter, the > > >> receiver > > >> can indicate to the sender that it is not willing to receive more text > > >> using > > >> the direction attributes [ref-to-section-4.2.3]" > > >> > > >> I guess we could also say that the receiver might choose to close the T.140 data > > >> channel. > > >> > > >> "If the receiver receives text at a higher rate than it can handle, > > >> e.g., > > >> because the sender does not support the cps parameter, the > > >> receiver > > >> can either close the T.140 data channel, or maintain the data > > >> channel but > > >> indicate to the sender that it is not willing to receive more text > > >> using > > >> the direction attributes [ref-to-section-4.2.3]" > > > That would work for me. > > > > > > The receiver could IMHO also just use SCTP flow control to slow down the sender. If the receiver only reads data from the SCTP > > > receive buffer with rate cps, the sender will not be able to transmit faster than cps once SCTP flow control kicks in and the SCTP send > > > buffer fills up. A similar effect will happen if the network is very slow and cannot deliver the data rate needed to deliver cps (which is > > > most likely a rare event in today's Internet for these low bit rates, but clearly it can happen in corner cases). In those cases, it could be > > > beneficial not to have huge send buffers inside SCTP as data can get queued there, too. > > > > > > Maybe it would make sense to add a heads-up in the document to take into account potential buffering inside SCTP when sizing buffers. > > > > > > [GH] I don't like the text about closing the channel. Using SCTP flow > > > control sounds better if that is an available action from WebRTC > > > applications. Real-time text transmission needs to be equally robust as > > > audio and video transmission, because it is used as an alternative to > > > these media. Therefore we should not attract implementors to ideas of > > > reducing its robustness. Saying that, I realize that it could instead > > > build up huge queues of text, or cause receiver buffer overflow so that > > > text will be lost. But that is better handled by user decisions about > > > what to do with the call. > > > > First, it is NOT within the scope of this document to define how to implement flow control on WebRTC data channels. > > I know that it has been discussed in the WebRTC community, and a quick search gave me this: > > > > https://github.com/pion/webrtc/tree/master/examples/data-channels-flow-control > > > > Second, as I indicated earlier, I really don't think data channel overloading is going to be a problem with T.140. If people > > try to use it for non-intended things (file transfer etc), and it doesn't work, it is not up to this spec to fix it. > > > > Having said that, we can of course indicate that if a flow control mechanism will be available in the future, the receiver can > > use that. Something like: > > > > "If the receiver receives text at a higher rate than it can handle, e.g., > > because the sender does not support the cps parameter, the receiver > > indicate to the sender that it is not willing to receive more text at the moment, > > using the direction attributes [ref-to-section-4.2.3]. If that does not help, the > > receiver can close the T.140 data channel." > > > > NOTE: At the time of writing this specification, a flow control mechanism for WebRTC data channels > > had not been standardized. Should such be available at some point, the receiver might use it in order > > to slow down the rate of text received from the sender." > > > >[GH] > > a)On the third line, did you mean "can indicate" or "indicates" ? I prefer "can indicate" slightly. > > b)I dont like the sentence about closing the channel. Please delete. This is just an example of implementor's actions. It > > might be better to discard chunks of received text and replace it with one mark for missing text. > > c)The note is good > > New try: > > "If the receiver receives text at a higher rate than it can handle, e.g., > because the sender does not support the cps parameter, the receiver > can indicate to the sender that it is not willing to receive more text at the moment > by using the direction attributes [ref-to-section-4.2.3]. > > NOTE: At the time of writing this specification, a flow control mechanism for WebRTC data channels > had not been standardized. Should such be available at some point, the receiver might use it in order > to slow down the rate of text received from the sender." > > --- > > 3/ > > ... > > > >> > So, in order to sort out the text and explain the two different ways to use > > >> the transmission buffer I suggest the following wording for 5.3: > > >> > > > >> > OLD 5.3: > > >> > > > >> > "As described in [T140], buffering can be used to reduce overhead, with > > >> the maximum buffering time being 500 ms. It can also be used for staying > > >> > within the maximum character transmission rate (Section 4.2), if such > > >> has been provided by the peer. > > >> > An implementation needs to take the user requirements for smooth > > >> flow and low latency in real-time text conversation into consideration when > > >> > assigning a buffer time. It is RECOMMENDED to use the default > > >> transmission interval of 300 milliseconds [RFC4103], or lower, for T.140 data > > >> channels." > > >> > > > >> > NEW: > > >> > > > >> > "As described in [T140], buffering can be used to reduce overhead, with > > >> the maximum transmission interval as long as there is text to send being 500 > > >> ms. > > >> > Buffering can also be used for staying within the maximum character > > >> transmission rate (Section 4.2.1). > > >> > > > >> > An implementation needs to take the user requirements for smooth > > >> flow and low latency in real-time text conversation into consideration when > > >> assigning a > > >> > buffer time. It is RECOMMENDED to use the default transmission > > >> interval of 300 milliseconds [RFC4103], for T.140 data channels. Implementers > > >> MAY also use > > >> > lower values, for specific applications requiring low latency, taking the > > >> increased overhead in consideration." > > >> > > > >> > Note that I added more wording about the lower transmission interval. I got > > >> the impression that that was desired as discussed below. > > >> > > >> [CH] I am fine with your suggested new text, but it does not address the case > > >> when the interval exceeds 500 ms (e.g., because the sender is about to exceed > > >> the cps value). > > > The proposed text is better than the original wording. > > > > > > As already mentioned, there would (or at least could) be two buffers in the sender: > > > * A buffer in the T.140 message processing (at application level), from which data is handed over to SCTP > > > * A send buffer inside the SCTP stack used e.g. for retransmissions > > > > > > The maximum amount of data that can be queued in the sender is the sum of both buffers. In contrast, as far as I > > > understand, an RFC4103 implementation conceptually may only have one buffer. So, here the different transports > > > actually matter. > > > > > > My understanding is that the "buffer time" would _only_ include the application-level buffer. In that case, it could be useful > > > to mention that addition queuing inside the transport protocol implementation is possible and should be taken into account > > > when setting values. > > > > > > [GH] To [CH]: Deletion of the term "500 ms maximum buffering time" and > > > replacing it with a "maximum transmission interval of 500 ms" was > > > intended to show that some characters might stay in buffers longer than > > > 500 ms if production is more rapid than the CPS, but that transmission > > > is continued at every transmission interval with the number of > > > characters allowed within the CPS mean value, but possibly leaving some > > > characters in the buffer until next interval. The wording "500 ms > > > maximum buffering time" was misleading. Woops, I realize that the text > > > proposal still contains one "maximum buffering time". Can you please > > > replace that also with "transmission interval". Can you after that > > > change still read it as if a solution would be to temporarily increase > > > the transmission interval if the CPS value is reached? > > > > First, I did not find the remaining "maximum buffering time". > > > > Send, based on your suggestion, the end of the first sentence now sounds strange. > > > > "As described in [T140], buffering can be used to reduce overhead, with > > the maximum transmission interval as long as there is text to send being 500 > > ms." > > > > Third, doesn't T.140 specify that the max buffering time is 500 ms? We shouldn't change that. > > > > [GH] New proposal with the last remaining "buffer time" also replaced: > > > > NEW > > > > "As described in [T140], buffering can be used to reduce overhead, with > > the maximum assigned transmission interval of T140blocks from the buffer > > being 500 ms as long as there is text to send. > > > > Buffering can also be used for staying within the maximum character > > transmission rate (Section 4.2.1). > > > > An implementation needs to take the user requirements for smooth > > flow and low latency in real-time text conversation into consideration when > > assigning a transmission interval. It is RECOMMENDED to use the default transmission > > interval of 300 milliseconds [RFC4103], for T.140 data channels. Implementers > > MAY also use lower values, for specific applications requiring low latency, taking the > > increased overhead in consideration." > > Looks ok. I suggest to go with that. > > --- > > 4/ > > > >> >>> [CH] I guess it depends on whether the recommendation is to > > >> specifically use > > >> >>> 300ms, or whether the recommendation is to use 300 or lower. RFC > > >> 4103 talks > > >> >>> about specifically using 300ms, so I think we should follow that for T.140 > > >> data > > >> >>> channels. So, I am fine with the text you suggest. > > >> >>> > > >> >> OK, then we may have sorted this out > > >> >> > > >> > [GH] See my proposal for 5.3 above > > >> > > >> [CH] For synch purpose, no actions for this issue is currently identified, as it is > > >> covered by the suggested way to address issue 3/ > > > > Still no action for this issue. > > Still no action. > > --- > > 5/ > > ... > > > > >> >> > > >> > GH] I suggest slight modifications > > >> > > > >> > NEW2 > > >> > "In case of network failure or congestion, T.140 data channels might > > >> > fail and get torn down. If this happens but the session sustains, it > > >> > is RECOMMENDED that implementations tries to reestablish the T.140 > > >> > data channels. As a T.140 data channel does not provide a mechanism > > >> > for the receiver to identify retransmitted T140blocks after channel > > >> reestablishment, the sender MUST > > >> > NOT retransmit T140blocks unless it has strong indications that a > > >> T140block has been lost. Similarly, as a T.140 > > >> > data channel does not provide a mechanism for a receiver to detect > > >> lost T140blocks during channel reestablishment, it > > >> > SHOULD NOT insert missing text markers [T140ad1] unless it has > > >> reasons to suspect that a T140block might have been lost. > > >> > Different mechanisms used by senders and receivers to detect or > > >> suspect packet loss are outside the scope of this specification." > > >> > > > >> > Regarding the change for the receiving side, it is better to insert a loss > > >> mark too much than omitting one. > > >> > > >> [CH] Ok. However, I think we could use "MUST NOT insert missing text > > >> markers unless it has reasons to suspect". > > >> > > >> Because, why would the receiver insert a missing text marker if it does not > > >> suspect that a T140block has been lost? > > > Both variants work for me. At the end of the day, this is mostly about the question what > > > service is delivered to the user. > > > > > > [GH] Yes, I can accept your wording[CH] for the second part of the text. > > > > Ok, so the current suggestion is to add the following text: > > > > "In case of network failure or congestion, T.140 data channels might > > fail and get torn down. If this happens but the session sustains, it > > is RECOMMENDED that implementations tries to reestablish the T.140 > > data channels. As a T.140 data channel does not provide a mechanism > > for the receiver to identify retransmitted T140blocks after channel > > reestablishment, the sender MUST NOT retransmit T140blocks unless > > it has strong indications that a T140block has been lost. 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 senders and receivers to detect or > > suspect packet loss are outside the scope of this specification." > > > > --- > > [GH]A small correction: on third line, it should read "implementations try" > > Current suggestion is to add the text above, with the change suggested by Gunnar. > > Regards, > > Christer > -- + + + + + + + + + + + + + + Gunnar Hellström Omnitor gunnar.hellstrom@xxxxxxxxxx +46 708 204 288 -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
