Re: [Tsv-art] Tsvart last call review of draft-ietf-mmusic-t140-usage-data-channel-11 - the pull request

[Christer Holmberg <[e-mail]>]

Hi,

I have updated the pull request (it also contains the changes based on Adam's AD review) based on the TSVART comments from Michael.

https://github.com/cdh4u/draft-datachannel-t140/pull/55/files

Regards,

Christer





On 02/02/2020, 23.42, "Christer Holmberg" <[e-mail]> wrote:

    Hi Michael,
    
    Regarding 2/, I am fine modifying the note so that it talks about the WebRTC API.
    
    Regards,
    
    Christer
    
    
    On 02/02/2020, 23.25, "Scharf, Michael" <[e-mail]> wrote:
    
        Inline regarding /2
        
        > -----Original Message-----
        > From: Gunnar Hellström <[e-mail]>
        > Sent: Sunday, February 2, 2020 10:19 PM
        > To: Christer Holmberg <[e-mail]>; Scharf, Michael
        > <[e-mail]>; [e-mail]
        > Cc: [e-mail]; [e-mail]; draft-ietf-mmusic-t140-usage-data-
        > [e-mail]
        > Subject: Re: Tsvart last call review of draft-ietf-mmusic-t140-usage-data-
        > channel-11
        > 
        > Hi,
        > 
        > I am fine with all Christer's conclusions and proposals below.
        > 
        > Gunnar
        
        ...
         
        > >      2/
        > >
        > >      ...
        > >
        > >      >      >>
        > >      >      >> [CH]  Just to keep everyone in sync, the current proposal is to add
        > some text
        > >      >      >> like:
        > >      >      >>
        > >      >      >>                    "If the receiver receives text at a higher rate than it
        > can handle,
        > >      >      >> e.g.,
        > >      >      >>                      because the sender does not support the cps
        > parameter, the
        > >      >      >> receiver
        > >      >      >>                      can indicate to the sender that it is not willing to
        > receive more text
        > >      >      >> using
        > >      >      >>                      the direction attributes [ref-to-section-4.2.3]"
        > >      >      >>
        > >      >      >> I guess we could also say that the receiver might choose to close
        > the T.140 data
        > >      >      >> channel.
        > >      >      >>
        > >      >      >>                    "If the receiver receives text at a higher rate than it
        > can handle,
        > >      >      >> e.g.,
        > >      >      >>                      because the sender does not support the cps
        > parameter, the
        > >      >      >> receiver
        > >      >      >>                      can either close the T.140 data channel, or maintain
        > the data
        > >      >      >> channel but
        > >      >      >>                      indicate to the sender that it is not willing to receive
        > more text
        > >      >      >> using
        > >      >      >>                      the direction attributes [ref-to-section-4.2.3]"
        > >      >      > That would work for me.
        > >      >      >
        > >      >      > The receiver could IMHO also just use SCTP flow control to slow
        > down the sender. If the receiver only reads data from the SCTP
        > >      >      > receive buffer with rate cps, the sender will not be able to transmit
        > faster than cps once SCTP flow control kicks in and the  SCTP send
        > >      >      > buffer fills up. A similar effect will happen if the network is very
        > slow and cannot deliver the data rate needed to deliver cps (which is
        > >      >      > most likely a rare event in today's Internet for these low bit rates,
        > but clearly it can happen in corner cases). In those cases, it could be
        > >      >      > beneficial not to have huge send buffers inside SCTP as data can get
        > queued there, too.
        > >      >      >
        > >      >      > Maybe it would make sense to add a heads-up in the document to
        > take into account potential buffering inside SCTP when sizing buffers.
        > >      >      >
        > >      >      > [GH] I don't like the text about closing the channel. Using SCTP flow
        > >      >      > control sounds better if that is an available action from WebRTC
        > >      >      > applications. Real-time text transmission needs to be equally robust
        > as
        > >      >      > audio and video transmission, because it is used as an alternative to
        > >      >      > these media. Therefore we should not attract implementors to
        > ideas of
        > >      >      > reducing its robustness. Saying that, I realize that it could instead
        > >      >      > build up huge queues of text, or cause receiver buffer overflow so
        > that
        > >      >      > text will be lost. But that is better handled by user decisions about
        > >      >      > what to do with the call.
        > >      >
        > >      >  First, it is NOT within the scope of this document to define how to
        > implement flow control on WebRTC data channels.
        > >      > I know that it has been discussed in the WebRTC community, and a quick
        > search gave me this:
        > >      >
        > >      > https://protect2.fireeye.com/v1/url?k=67c8352f-3b433e15-67c875b4-86925ec6fd56-28ed2d5918dddf1f&q=1&e=023dcdfe-9815-4083-bc75-b6f1e1a2f7a6&u=https%3A%2F%2Fgithub.com%2Fpion%2Fwebrtc%2Ftree%2Fmaster%2Fexamples%2Fdata-channels-
        > flow-control
        > >      >
        > >      > Second, as I indicated earlier, I really don't think data channel
        > overloading is going to be a problem with T.140. If people
        > >      > try to use it for non-intended things (file transfer etc), and it doesn't
        > work, it is not up to this spec to fix it.
        > >      >
        > >      > Having said that, we can of course indicate that if a flow control
        > mechanism will be available in the future, the receiver can
        > >      > use that. Something like:
        > >      >
        > >      >           "If the receiver receives text at a higher rate than it can handle,
        > e.g.,
        > >      >             because the sender does not support the cps parameter, the
        > receiver
        > >      >             indicate to the sender that it is not willing to receive more text at
        > the moment,
        > >      >             using the direction attributes [ref-to-section-4.2.3]. If that does
        > not help, the
        > >      >             receiver can close the T.140 data channel."
        > >      >
        > >      >             NOTE: At the time of writing this specification, a flow control
        > mechanism for WebRTC data channels
        > >      >            had not been standardized. Should such be available at some
        > point, the receiver might use it in order
        > >      >            to slow down the rate of text received from the sender."
        > >      >
        > >      >[GH]
        > >      > a)On the third line, did you mean "can indicate" or "indicates" ? I prefer
        > "can indicate" slightly.
        > >      > b)I dont like the sentence about closing the channel. Please delete. This
        > is just an example of implementor's actions. It
        > >      > might be better to discard chunks of received text and replace it with
        > one mark for missing text.
        > >      > c)The note is good
        > >
        > > New try:
        > >
        > >                    "If the receiver receives text at a higher rate than it can handle,
        > e.g.,
        > >                    because the sender does not support the cps parameter, the
        > receiver
        > >                    can indicate to the sender that it is not willing to receive more
        > text at the moment
        > >                    by using the direction attributes [ref-to-section-4.2.3].
        > >
        > >                    NOTE: At the time of writing this specification, a flow control
        > mechanism for WebRTC data channels
        > >                   had not been standardized. Should such be available at some
        > point, the receiver might use it in order
        > >                   to slow down the rate of text received from the sender."
        
        I am not deeply familiar with the internals of WebRTC. However, as far as I currently understand, there is standardized flow control for WebRTC data channels - inside SCTP. Yet, I read that the WebRTC API does not expose that functionality. If that is indeed correct, I believe a better wording would be:
        
          NOTE: At the time of writing this specification, the standardized API to WebRTC data channels does not support flow control. Should such be available at some point,  the receiver might use it in order to slow down the rate of text received from the sender."
        
        Other experts on WebRTC could chime in...
        
        Michael