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

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

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]>
> *Date: *Tuesday, 7 April 2020 at 12.49
> *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,
>
> 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]>
>     <mailto:[e-mail]>
>     *Date: *Tuesday, 7 April 2020 at 8.04
>     *To: *Christer Holmberg <[e-mail]>
>     <mailto:[e-mail]>
>     *Cc: *Gunnar Hellstrom <[e-mail]>
>     <mailto:[e-mail]>, "[e-mail]"
>     <mailto:[e-mail]> <[e-mail]> <mailto:[e-mail]>,
>     "[e-mail]"
>     <mailto:[e-mail]>
>     <[e-mail]>
>     <mailto:[e-mail]>,
>     Flemming Andreasen <[e-mail]>
>     <mailto:[e-mail]>, "[e-mail]"
>     <mailto:[e-mail]> <[e-mail]>
>     <mailto:[e-mail]>, "[e-mail]"
>     <mailto:[e-mail]> <[e-mail]> <mailto:[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]
>     <mailto:[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]> 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]
>         >> https://www.ietf.org/mailman/listinfo/mmusic
>
>         -- 
>
>         + + + + + + + + + + + + + +
>
>         Gunnar Hellström
>         Omnitor
>         [e-mail] <mailto:[e-mail]>
>         [phone]
>
>
> -- 
> + + + + + + + + + + + + + +
> Gunnar Hellström
> Omnitor
> [e-mail]  <mailto:[e-mail]>
> [phone]

-- 

+ + + + + + + + + + + + + +

Gunnar Hellström
Omnitor
[e-mail]
[phone]