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

[Christer Holmberg <[e-mail]>]

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.

Regards,

Christer