Re: [MMUSIC] Martin Duke's Discuss on draft-ietf-mmusic-t140-usage-data-channel-12: (with DISCUSS and COMMENT)

[Martin Duke <[e-mail]>]

Hi Christer,

I gather that is the common use case of sendonly, but in this particular
case we are changing the directionality of the data channel to prevent a
buffer overflow.

I have no strong opinion on the correct behavior here, but I think the
buffering section should address it.

Thanks.

On Sun, Apr 5, 2020 at 12:17 PM Christer Holmberg <
[e-mail]> wrote:

> Hi,
>
> > If I understand correctly, senders would still buffer T.140 blocks if
> over the limit, or while the peer is in sendonly, to
> > preserve the reliability properties of the channel.
>
> I don't think there is a requirement for that. If the peer is sendonly, it
> means that it does not want to receive anything and that the network should
> only be used for uni-directional media. For example, in the cause of audio
> or video, the sender is not required to (and, in my experience, will never)
> buffer the audio/video in the case of sendonly (or inactive). Sendonly
> means that the application should not try to send anything to begin with,
> and should inform the user about that. I assume this apply to an RFC4103
> compliant sender too.
>
> Regards,
>
> Christer
>
>
>
>
>
>  It would be good to also say in 5.3 that this MUST(?) happen without any
> regard for time limits.
> Yes, the intention is to not lose any text even if the sending user
> creates more text than the receiver can receive and present.
> However, even if real-time text is intended for human conversation, it is
> common that real-time text user interfaces have a cut-and paste function.
> It is also still possible that a session will be connected through a
> gateway to a TTY ( a US textphone  in the PSTN), with the extremely slow
> reception rate of about 5 characters per second. (Yes, it is true, there
> might still be the case, e.g. in contact with 9-1-1 emergency services). A
> user, using the paste function of the relatively small amount of text 300
> characters, will block the transmission for 60 seconds in that session
> before the real-time flow of typing can be regained. Then it is good that
> the buffer is at the sender side, so that the sending user can be informed
> and maybe provided with the option to interrupt or cancel the transmission
> of the pasted text so that typed transmission in real time can be regained.
> Such options in the user interface are out of scope for the current spec,
> but it is good to know that that opportunity is there, rather than to send
> the whole chunk of text out to a combination of network devices and far end
> legacy user device without control of where buffer overflow and loss might
> occur.
> Regards
> Gunnar
>
>
> Martin
>
> On Sun, Apr 5, 2020 at 12:15 AM Gunnar Hellström <mailto:
> [e-mail]> wrote:
> Hi Martin,
>
> I can start answering with some clarifications.
>
> Den 2020-04-05 kl. 03:03, skrev Martin Duke via Datatracker:
> > Martin Duke has entered the following ballot position for
> > draft-ietf-mmusic-t140-usage-data-channel-12: Discuss
> >
> > When responding, please keep the subject line intact and reply to all
> > email addresses included in the To and CC lines. (Feel free to cut this
> > introductory paragraph, however.)
> >
> >
> > Please refer to
> https://www.ietf.org/iesg/statement/discuss-criteria.html
> > for more information about IESG DISCUSS and COMMENT positions.
> >
> >
> > The document, along with other ballot positions, can be found here:
> >
> https://datatracker.ietf.org/doc/draft-ietf-mmusic-t140-usage-data-channel/
> >
> >
> >
> > ----------------------------------------------------------------------
> > DISCUSS:
> > ----------------------------------------------------------------------
> >
> > I am confused as to the expected/allowed behavior regarding the cps
> attribute
> > parameter.
> >
> > In RFC 4103 Section 6 it says receivers MUST be able to handle temporary
> bursts
> > over the cps rate but senders MUST stay below the rate.
> >
> > In section 5.3 it says senders “can” (probably need a 2119 word here)
> buffer
> > blocks to stay below cps. There is a 500ms limit so this has its
> limitations.
> > Shouldn’t the buffer time be unbounded if characters are coming in at a
> rate
> > above cps?
>
> The 500 ms limit is on the sending side. A more normal time is 300 ms.
>
> The idea is that the reader want to have a smooth flow of incoming text
> to read. In 4.2.1 it is said that CPS is calculated over a 10 second
> period. If the sender reaches the CPS limit, and then waits the usual
> 300 ms, then a calculation is done to check how many characters can be
> transmitted at that point in time to keep under the CPS limit. If the
> flow has been high but even, it might be found that it is possible to
> send 10 characters from the buffer, but 290 characters need to wait.
> These 290 characters are not available for sending at the moment because
> that would make the CPS exceeded.
>
> It might also be found that no character can be allowed to be sent, e.g.
> because the sending user just recently had pasted a chunk of 300
> characters of text that was transmitted so that the CPS calculation over
> 10 seconds is still 30.
>
> The first paragraph in 5.3 ends " as long as there is text to send."
> That is intended to take the CPS calculation into consideration and
> regard only characters allowed to be transmitted while keeping under the
> CPS over a 10 second period to be "text to send".
>
> The wording "as long as there is text to send." might be improved. I
> leave to Christer to propose a conclusion.
>
> >
> > Meanwhile in section 4.2.1 it suggests that receivers use sendOnly or
> inactive
> > (I presume these are the right direction values) to effectively flow
> control
> > the incoming data. 4566bis seems to only envision this at the start of a
> > channel.
>
> In RFC4566bis it is said about inactive: "This is necessary for
> interactive multimedia conferences where users can put other users on
> hold."
>
> It is possible to send sdp during the session to modify the session.
> This is also stated in section 4.2.3.4. The usage of the direction
> attributes for the T140 data channel is registered in section 9.4, and
> rfc4566bis says in section 8.2.4.2 that new use of existing attributes
> shall be registered and that offer/answer procedures may be specified
> for the new use (in this case for the use in dcsa in the t140 data
> channel). In section 4.2.3 it is also stated that the principles of
> offer/answer procedures in rfc 3264 for the direction attributes apply
> (as it also does for the original direction attributes in rfc4566bis).
> In rfc 3264 section 8.4 it is clear that the attributes can be changed
> during the session.
> So, I think we are safe in multiple ways here. The use is registered and
> it is the same as intended in rfc4566bis and RFC 3264.
>
>
> >   What is the impact of pending data if the directionality of the
> > channel changes? How does this interact with the maximum buffer time?
> Text would be held and not be regarded to be "text to send".
> >
> > I suggest 4.2.1 be clearer on what actions a cps sender and receiver
> > MAY/SHOULD/MUST take, and make sure there aren’t contradictory
> requirements.
>
> Thanks, maybe the solution is to find an improvement of the words "as
> long as there is text to send" in 5.3. Let us see what Christer proposes.
>
> Regards
>
> Gunnar
>
> >
> >
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> >
> > The Tsvarea review cites a few other places where the 2119 language is a
> little
> > loose, e.g. MUSTs with vague and unenforceable criteria.
> >
> >
> >
> > _______________________________________________
> > mmusic mailing list
> > mailto:[e-mail]
> > https://www.ietf.org/mailman/listinfo/mmusic
>
> --
>
> + + + + + + + + + + + + + +
>
> Gunnar Hellström
> Omnitor
> mailto:[e-mail]
> [phone]
> --
>
> + + + + + + + + + + + + + +
>
> Gunnar Hellström
> Omnitor
> mailto:[e-mail]
> [phone]
>
>