Hi, yes it is converging. I have a few more comments. Den 2020-01-31 kl. 15:47, skrev Scharf, Michael: > Hi all, > > in general, I believe that this is useful discussion heading into the right direction. > > More inline. > > Michael > >> 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. > 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. > >> ----- >> >> 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]" > 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. > >> --- >> >> 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). > 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? To [MS] Yes, there are characters even in the SCTP stack. Also for the RFC 4103 case, it is very common with buffers on lower levels in the transmission stack (e.g. WiFi). I don't mind some words about SCTP buffers. > >> --- >> >> 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? > 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. > > Michael Regards Gunnar -- + + + + + + + + + + + + + + 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
