Hi,
I have removed much of the text, but I have kept the issue numbers for reference.
---
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.
-----
2/
...
>>>> [MS] From a transport protocol design perspective, the „cps“ parameter may
>>>> realize some sort of (simple) flow control. And in that case sender and receiver
>>>> typically have to agree on the semantics. And your example actually describes
>>>> a typical flow control problem: If a 4 cps receiver receives 1000 characters, it
>>>> may actually be interested in slowing down the sender. Could it do so, for
>>>> instance, by sending cps=0? As far as I understand the I-D, this would be
>>>> allowed. How to deal with that case is not a local implementation issue only.
>>>> Well, we are here probably discussing corner cases of corner cases. But as far
>>>> as I can see, the document does not comprehensively describe the use of the
>>>> cps attribute.
>>>>
>>> [CH] If the receiver cannot handle the received characters, in my opinion it is
>>> better if it uses the direction attributes (4.2.3) to indicate that it is not willing to
>>> receive text. I guess we could add some text about 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
>>> can indicate to the sender that it is not willing to receive more text using
>>> the direction attributes [ref-to-section-4.2.3]"
>>>
>>> With that being allowed, it becomes even less apparent to me why the cps parameter is needed at all.
>>>
>> It is used in order to help to prevent buffer overflow and sending of I-do-not-want-more-text requests to be sent.
>>
>> I really don't understand what the problem is by having a way to indicate the maximum rate. Having legacy equipment
>> that do not support certain protocol elements is nothing new in IETF, and not specific to data channels, but that hasn't
>> prevented us from adding new features etc when we specify new versions of protocols etc.
>>
>>> Also, SCTP has flow control, which should also be able to slow down a sender, or even stop it in case of a slow receiver. From the document is not
>>> really clear to me if the T.140-specific rate mechanisms (cps) and buffer timeouts (300/500ms) interact with underlying send and receive buffers for the data channel, and if so, how.
>>>
>> No matter what data channel usage you have, whatever you send and at whatever rate, the underlying transport mechanism (SCTP) obviously need to support it.
>>
>>> I am not really familiar with WebRTC internals, but running some sort of rate-controlled traffic with soft real-time delay requirements over a reliable
>>> transport channel is typically not trivial. In this specific use case, the data rate is expected to be so small that it should usually work well. But, nonetheless,
>>> there could be corner cases in particular in challenging network environments and the document is silent about them.
>>>
>>The current version of the data channel specification does not contain load balance and rate control - applications need to
>> make sure they don't try to send more than the data channel can handle.
>>
>> However, I don't overloading the SCTP association is going to be a problem in the case of T.140.
[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]"
---
3/
...
>>>> [CH] I don't know whether it is within the scope of this document to normatively
>>>> define that characters shall be dropped if they cannot be transmitted within
>>>> 500ms. In my opinion that is part of the generic T.140 procedures, not specific
>>>> to data channels. But, perhaps we could say something like:
>>>>
>>>> "If a character cannot be transmitted within 500ms, and the sender
>>>> chooses to drop the character from the buffer. If that happens, the
>>>> sender SHOULD inform the user about it."
>>>>
>>> That makes sense to me.
>>>
>> Thanks! I will add it.
>>
> [GH] No, I do not think that is a good implementation ever.
>
> Let me start with another small correction to do in this area.
>
>This sentenct in the first paragraph of 5.3 is not logical anymore and should be modified:
>
>
> OLD
>
> "It can also be used for staying within the maximum character transmission rate (Section 4.2), if such has been provided by the peer."
>
> NEW
>
> "It can also be used for staying within the maximum character transmission rate (Section 4.2.1)."
>
> Because we changed in 4.2.1 so that there is now always a maximum transmission rate with the default being 30 cps.
[CH] Makes sense. I can modify as suggested.
> Now, let us solve the wording about buffering.
>
> 5.3 starts with:
>
> "As described in [T140], buffering can be used to reduce overhead, with the maximum buffering time being 500 ms."
>
> This requirement comes from T.140. Research has shown that users of human typed text conversation can accept one second
> delay from typing to remote presentation. The maximum of 500 ms buffering time allows 500 ms for network transmission and remote presentation.
>
> This is the maximum. There is a better user experience if the delay can be a bit shorter. Therefore RFC 4103 RECOMMENDS 300 ms buffering time
> between transmissions as a balance between delay and overhead. And we have copied that recommendation into next paragraph, with the added
> consideration that some modern automatic applications benefit from shorter buffering time (down to 100 ms).
>
> The expression "buffering time" would have been better expressed if it said "transmission interval".
>
> The second use of the transmission buffer is for the case when we need to limit the flow because of the CPS parameter value. This is mentioned in the
> second sentence (corrected above).
> Even if some text cannot be transmitted within the 500 ms limit because we are on the way to exceed the CPS value, the text does not become
> worthless immediately. It should be stored in a buffer, and as much as can be transmitted because of the CPS value will be transmitted from that
> buffer at each transmission interval.
>
> If a sending user happened to type extremely fast for a long time, or in some other way fill the transmission buffer so that it takes a very long time
> to send it, the receiving user will experience that they lost real-time conversational contact. I cannot see any better option than letting the receiving
> user have the usual option to hang up.
>
> 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).
---
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/.
---
5/
...
>>> [MS] Anyway, I agree that the current specification allows „smarter“ solutions
>>> simply by omitting details on (well, granted) corner cases. The question is
>>> whether the current spec is precise enough to ensure interoperability between
>>> implementations and to fully describe the characteristics to potential users. I
>>> don’t understand this use case well enough and therefore I defer that question
>>> to the TSV ADs.
>>
>> [CH] Perhaps we could remove "already successfully transmitted T140blocks",
>> since there currently is no way to verify that. Maybe something like:
>>
>> OLD:
>>
>> "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. If reestablishment of the T.140 data channel is
>> successful, an implementation MUST evaluate if any T140blocks were
>> lost. Retransmission of already successfully transmitted T140blocks
>> MUST be avoided, and missing text markers [T140ad1] SHOULD be
>> inserted in the received data stream where loss is detected or
>> suspected."
>>
>> NEW:
>>
>> "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, the sender MUST
>> NOT retransmit T140blocks unless it has strong reasons to suspect 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, it MUST NOT insert missing text markers [T140ad1]
>> unless it has strong reasons to suspect that a T140block has been lost.
>> Different mechanisms used by senders and receivers to suspect packet loss
>> Is outside the scope of this specification."
>>
>> That looks better to me.
>>
> 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?
Regards,
Christer
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
