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

[Martin Duke <[e-mail]>]

Is that inconsistent with MAY?

On Wed, Apr 8, 2020, 23:17 Christer Holmberg <[e-mail]>
wrote:

> Hi,
>
>
>
> > The changes look good. One more thing. In 5.3:
>
> >
>
> > Buffering can also be used for staying within the maximum character
> transmission rate
>
> >
>
> > could we change this to either SHOULD or MAY (whichever you think is
> best)?
>
>
>
> I think I’d prefer to keep “can”. Because, it would also be handled e.g.,
> on the application level.
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
>
>
> On Wed, Apr 8, 2020 at 12:06 PM Christer Holmberg <
> [e-mail]> wrote:
>
> Hi Martin,
>
>
>
> >This is good, because it specifies what the receiver should do when the
> sender violates RFC 4103.
>
> >
>
> >There still isn't guidance on what senders should do, but IMO that is an
> RFC 4103 problem, not a problem with this draft.
>
> >
>
> >Can you summarize the total change you plan to make to the draft in
> response to my DISCUSS? There was a different thread about 5.3
>
> >that is related and I'd like to make sure they are addressed holistically.
>
>
>
> The changes based on your review can be seen in the following PullRequest
> commits:
>
>
>
>
> https://github.com/cdh4u/draft-datachannel-t140/pull/56/commits/432cc24a42cec7f084657738bd2b69a8c2f9d380
> <https://protect2.fireeye.com/v1/url?k=2b3d9cd7-77e995b1-2b3ddc4c-8610d8a762ca-7a63a12d6e3ecb7c&q=1&e=6c92bb4f-5cff-4c3f-a9cc-c62ea882de13&u=https%3A%2F%2Fgithub.com%2Fcdh4u%2Fdraft-datachannel-t140%2Fpull%2F56%2Fcommits%2F432cc24a42cec7f084657738bd2b69a8c2f9d380>
> (“strong indication” issue)
>
>
>
>
> https://github.com/cdh4u/draft-datachannel-t140/pull/56/commits/90c6ff8625004262cce1a434a34b5dae03356932
> <https://protect2.fireeye.com/v1/url?k=05b7a05c-5963a93a-05b7e0c7-8610d8a762ca-a9aa36bfd80a5723&q=1&e=6c92bb4f-5cff-4c3f-a9cc-c62ea882de13&u=https%3A%2F%2Fgithub.com%2Fcdh4u%2Fdraft-datachannel-t140%2Fpull%2F56%2Fcommits%2F90c6ff8625004262cce1a434a34b5dae03356932> (sendonly
> issue)
>
>
>
> (If you prefer me to write the changes in an e-mail reply I can do that.)
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *From: *Gunnar Hellstrom <[e-mail]>
> *Date: *Tuesday, 7 April 2020 at 14.04
> *To: *Christer Holmberg <[e-mail]>, Martin Duke <
> [e-mail]>
> *Cc: *"[e-mail]" <[e-mail]>, "
> [e-mail]" <
> [e-mail]>, Flemming Andreasen <
> [e-mail]>, "[e-mail]" <[e-mail]>, "
> [e-mail]" <[e-mail]>
> *Subject: *Re: [MMUSIC] Martin Duke's Discuss on
> draft-ietf-mmusic-t140-usage-data-channel-12: (with DISCUSS and COMMENT)
>
>
>
> Hi Christer,
>
> Den 2020-04-07 kl. 12:00, skrev Christer Holmberg:
>
> Hi,
>
>
>
> Your suggestion looks good. I suggest to include it in the same paragraph,
> as it is an exemption to the SHOULD.
>
> Yes, looks good, and my intention was to have it in the same paragraph, it
> was only the separation of your text and my text in the mail presentation
> that prevented me from that.
>
>
>
> Something like:
>
>
>
>    If an endpoint receives text at a higher rate than it can handle,
>
>    e.g., because the sending endpoint does not support the 'cps'
>
>    attribute parameter, it SHOULD either indicate to the sending endpoint
>
>    that it is not willing to receive more text, using the direction
>
>    attributes (Section 4.2.3), or use a flow control mechanism to
>
>    reduce the rate. However, in certain applications, e.g. emergency
> services,
>    it is important to regain human interaction as soon as possible, and it
> might
>
>    therefor be more appropriate to simply discard the received overflow,
> insert a
>
>    mark for loss [T140ad1], and continue to process the received text as
> soon as possible.
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
> Regards
>
> Gunnar
>
>
>
>
>
>
>
> *From: *Gunnar Hellstrom <[e-mail]>
> <[e-mail]>
> *Date: *Tuesday, 7 April 2020 at 12.49
> *To: *Christer Holmberg <[e-mail]>
> <[e-mail]>, Martin Duke <[e-mail]>
> <[e-mail]>
> *Cc: *"[e-mail]" <[e-mail]> <[e-mail]> <[e-mail]>,
> "[e-mail]"
> <[e-mail]>
> <[e-mail]>
> <[e-mail]>, Flemming Andreasen
> <[e-mail]> <[e-mail]>, "[e-mail]"
> <[e-mail]> <[e-mail]> <[e-mail]>,
> "[e-mail]" <[e-mail]> <[e-mail]> <[e-mail]>
> *Subject: *Re: [MMUSIC] Martin Duke's Discuss on
> draft-ietf-mmusic-t140-usage-data-channel-12: (with DISCUSS and COMMENT)
>
>
>
> Hi,
>
> This looks reasonably good. But there are cases when it is important to
> regain the real-time human conversation as soon as possible, and therefore
> discard the overflow instead of turning off the flow by a "sendonly".
> Real-time text is e.g. used in emergency services, and it would be more
> dangerous to turn off incoming text for an unforseeable time than to throw
> away some text and continue the dialogue. The mark for lost text can be
> inserted in the received text as soon as there is room for it.
>
> Therefore, I have proposed an added sentence in the first paragraph.
>
> Den 2020-04-07 kl. 09:36, skrev Christer Holmberg:
>
> Hi,
>
>
>
> Ok, so a new suggestion. What about the following modified text in Section
> 4.2.1:
>
>
>
>    If an endpoint receives text at a higher rate than it can handle,
>
>    e.g., because the sending endpoint does not support the 'cps'
>
>    attribute parameter, it SHOULD either indicate to the sending endpoint
>
>    that it is not willing to receive more text, using the direction
>
>    attributes (Section 4.2.3), or use a flow control mechanism to
>
>    reduce the rate.
>
>    In certain applications, e.g. emergency services,
>    it is however of importance to regain human interaction as soon as
>    possible, and therefore be more appropriate to discard the received
> overflow,
>    insert a mark for loss [T140ad1] as soon as possible in the received
> stream,
>    and be prepared to continue real-time conversation.
>
>
>
>    NOTE: At the time of writing this specification, the standardized API
>
>    for WebRTC data channels does not support flow control.  Should such
>
>    be available at some point, a receiving endpoint might use it in
>
>    order to slow down the rate of text received from the sending
>
>    endpoint.
>
>
>
> The text explicitly distinguish between the usage of the direction
> attributes and a flow control mechanism. The text is also “future proof”,
> as it describes the usage of a flow control mechanism as an alternative
> should such become available in the future.
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
> Regards
>
> Gunnar
>
>
>
>
>
>
>
> *From: *Martin Duke <[e-mail]> <[e-mail]>
> *Date: *Tuesday, 7 April 2020 at 8.04
> *To: *Christer Holmberg <[e-mail]>
> <[e-mail]>
> *Cc: *Gunnar Hellstrom <[e-mail]>
> <[e-mail]>, "[e-mail]" <[e-mail]>
> <[e-mail]> <[e-mail]>,
> "[e-mail]"
> <[e-mail]>
> <[e-mail]>
> <[e-mail]>, Flemming Andreasen
> <[e-mail]> <[e-mail]>, "[e-mail]"
> <[e-mail]> <[e-mail]> <[e-mail]>,
> "[e-mail]" <[e-mail]> <[e-mail]> <[e-mail]>
> *Subject: *Re: [MMUSIC] Martin Duke's Discuss on
> draft-ietf-mmusic-t140-usage-data-channel-12: (with DISCUSS and COMMENT)
>
>
>
> If sendonly is not a tool to use here, then that removes part of the
> confusion.
>
>
>
> If section 4.2.1 had a few sentences about what senders MUST, SHOULD, and
> MAY do when the user exceeds the peer CPS, including dropping frames if
> need be, that would make things much clearer.
>
>
>
> On Mon, Apr 6, 2020 at 2:08 PM Christer Holmberg <
> [e-mail]> wrote:
>
> Hi,
>
>
>
>  >>>>> 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.
>
>  >>>>
>
>  >>>> Perhaps we could say that the application may buffer text for a
> while in case of sendonly. But, the sendonly could “go on forever”,
>
>  >>>> so we cannot require that the application will accept and buffer all
> text during that time.
>
>  >>>>
>
>  >>>> The other alternative would have been to define a new
> please-hold-for-a-few-seconds attribute, but that would have meant more
>
>  >>>> work. And, in practice I don’t think this will be a big problem.
> Sure, you could have someone copy-pasting a large bunch of text, that
>
>  >>>> would cause a sendonly,  but in my opinion that is the wrong usage
> of a RTT function.
>
>  >>> When I answered Martin that text queued for transmission is kept, I
> meant for the case of reaching the CPS limit.
>
>  >>>
>
>  >>> I do not think that the sendonly should cause text to be buffered.
> People will sort out the appearing situations. We can hope that a proper
>
>  >>> flow control function is eventually implemented for data channels.
>
>  >> Works for me. I do agree that sendonly is not a flow control mechanism
> (that has been discussed in the past, and we don't want to re-open that
> discussion).
>
>  >>
>
>  >> Now, Martin DID ask for something to be said.  So, should we in
> Section 5.3 explicitly say that a change of the direction does not require
> buffering?
>
>  >
>
>  > I think that the decision means that the paragraph about direction
>
>  > attribute in 4.2.1 should be moved to the end of 4.2.3.4 and be
> slightly
>
>  > reworded to:
>
>  >
>
>  > If for example an endpoint receives text at a higher rate than it can
>
>  > handle, the receiving endpoint can indicate to the sending endpoint
> that
>
>  > it is not willing to receive more text, using the direction attribute
>
>  > "sendonly".
>
>
>
> So, first, the suggestion is to *remove* the following paragraph from
> Section 4.2.1:
>
>
>
>   "If an endpoint receives text at a higher rate than it can handle,
>
>    e.g., because the sending endpoint does not support the 'cps'
>
>    attribute parameter, the receiving endpoint can indicate to the
>
>    sending endpoint that it is not willing to receive more text at the
>
>    moment, using the direction attributes (Section 4.2.3)."
>
>
>
> Then, do we really need to add anything to 4.2.3.4? If we do, we will
> still end up with the does-the-remote-peer-buffer question. Could we just
> leave 4.2.3.4 as it is?
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
>
>
>
>
>
>
>
>
>
>
> > 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:mailto:[e-mail]
> <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:mailto:[e-mail] <mailto:[e-mail]>
> >> https://www.ietf.org/mailman/listinfo/mmusic
>
> --
>
> + + + + + + + + + + + + + +
>
> Gunnar Hellström
> Omnitor
> [e-mail]
> [phone]
>
> --
>
>
>
> + + + + + + + + + + + + + +
>
>
>
> Gunnar Hellström
>
> Omnitor
>
> [e-mail]
>
> [phone]
>
> --
>
>
>
> + + + + + + + + + + + + + +
>
>
>
> Gunnar Hellström
>
> Omnitor
>
> [e-mail]
>
> [phone]
>
>