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

[Paul Kyzivat <[e-mail]>]

On 4/6/20 5:36 PM, Christer Holmberg wrote:
> Hi,
> 
>>> 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?
>>
>> I think it depends on what the intent was of that paragraph. The current 
>> discussion seems to take it to mean that an endpoint that is being 
>> overwhelmed by excess incoming text might change the direction to 
>> sendonly in order to *throttle* the sender while it catches up. I'm 
>> inclined to agree with you that this is an inappropriate technique.
>>
>> An alternative interpretation is that in such a case the overwhelmed 
>> receiver may change the direction to sendonly in order to permanently 
>> silence the misbehaving sender. I have no problem with that.
> 
> I am fine describing the usage of sendonly, but the question is how we 
> make it clear that it is not a throttle/flow control mechanism, and that 
> the remote peer is not expected to buffer text etc.

Maybe just say that it SHOULD NOT be used as a flow control mechanism, 
leaving it (implicitly) open for use for other reasons.

	Thanks,
	Paul