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

[Martin Duke <[e-mail]>]

I updated it to make it clearer I consider it addressed.

On Fri, Apr 10, 2020 at 12:12 AM Murray S. Kucherawy <[e-mail]>
wrote:

> Martin,
>
> You left this comment in the datatracker:
>
> Old 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.
>
> Is that still the case?  I believe the authors felt they'd cleared all that up.
>
> -MSK
>
>
> On Thu, Apr 9, 2020 at 6:44 AM Martin Duke <[e-mail]>
> wrote:
>
>> Thanks for your work on this. You've fully addressed my DISCUSS.
>>
>> On Thu, Apr 9, 2020, 06:37 Christer Holmberg <
>> [e-mail]> wrote:
>>
>>> Hi,
>>>
>>>
>>>
>>> >Is that inconsistent with MAY?
>>>
>>>
>>>
>>> Perhaps not. I will change it to MAY.
>>>
>>>
>>>
>>> Regards,
>>>
>>>
>>>
>>> Christer
>>>
>>>
>>>
>>>
>>>
>>> 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]> <mmusic-chairs@ietf..org>, "[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]> <mmusic-chairs@ietf..org>, "[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]
>>>
>>>