Re: [Simple] Flood control in the msrp-switch

[Sebastian Dehne <dehne at colibria.com>]

> This is an issue, and in my opinion not at all unsimilar to the one 
> experienced when using MSRP relays. If a connected client keeps sending 
> faster than a slow client can receive, the buffer size at the MSRP 
> switch will grow infinitely large.
>
> In the end the policy for this should be decided by whomever runs the 
> MSRP chat switch, but I would imagine that the primary use for having 
> such a service is just that, i.e. chat. That means it should probably 
> not be used as some sort of large file distribution service. To this end 
> I would imagine that throttling incoming connections would not be a bad 
> idea.
>
> If this incoming throttling rate is set to a reasonable value, one can 
> also consider dropping connections to clients that cannot keep up with 
> the amount of data sent to them. The alternative would be to drop part 
> of the data to be sent to this slow client, which personally I would not 
> prefer to do.
>
> If you don't want to do either of this things, the only other thing I 
> could think of is some fancy many-to-many congestion control algorithm, 
> but really I wouldn't know where to begin dreaming that up...
>
> Any thoughts?
Hi Ruud,

I agree that dropping some of the data while keeping the connection 
alive is not an option. What you are saying makes sense to me. In other 
words, you could have throttling as a parameter which is set per 
chat-room. So a typical use-case would be to enable throttling for 
public rooms with many participants (no flooding of the channel 
possible) while private rooms for example, which DO want to have to 
possibility to transfer larger amount of data (such as sending a 
large-message to a grouup; as defined in the OMA SIMPLE-IM-TS 
specifications), it is disabled.

In any case where (whether throttling is enabled or disabled) and the 
msrp-switch still doesn't manage to write data to the slow participants, 
it simply has to kick them out of the room. The kicked-client could then 
choose to re-try be re-connection to the room or close the session.


Sebastian
_______________________________________________
Simple mailing list
Simple at ietf.org
https://www.ietf.org/mailman/listinfo/simple