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.
-----
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."
---
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.
---
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.
---
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."
---
Regards,
Christer
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
