Re: [Tsv-art] Tsvart last call review of draft-ietf-mmusic-t140-usage-data-channel-11

[Gunnar Hellström <[e-mail]>]

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
[e-mail]
[phone]