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

[Martin Duke <[e-mail]>]

Gunnar,

Thanks for the clarification. I agree that defining or rewording ‘text to
send’ solves the consistency issue.

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. It would be good to also say in 5.3 that this
MUST(?) happen without any regard for time limits.

Martin

On Sun, Apr 5, 2020 at 12:15 AM Gunnar Hellström <
[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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/mmusic
>
> --
>
> + + + + + + + + + + + + + +
>
> Gunnar Hellström
> Omnitor
> [e-mail]
> [phone]
>
>