[Simple] Flood control in the msrp-switch

[Sebastian Dehne <dehne at colibria.com>]

Hi,

I just read the currently published version of the draft and I was
wondering if it would be an idea to also address the following issue:

In the case where participants with different access-speeds are joined
in a chat-room, how should the msrp-switch deal with the situation when
it is not able to write data quickly enough to the slower participants?

For example a user with a relative fast connection could start to send a
large file into the chat-room which will cause the slower participants
to be blocked out from the chat-room until they managed to consume the
queued data. Also, should the switch just queue as long as it has memory
available?

They way this is solved in IRC for example is to slow down the sending
client by starting to respond slowly for each SEND request. However,
this is not a suitable solution for msrp, since it is indented to deal
with all sorts of content (including multi-media).

Maybe there is a need for a 'chat-type' attribute to distinguish between
for example 'conversation' or 'multi-media' rooms.

I think this is a realistic issue because of the following two reasons:

- SIP is well on its way to bridge between the 'internet-world' and the
'mobile-world'; two worlds with difference access-speeds
- simply because flooding a room could lead to a denial-of-service
attack in the case where the msrp-switch is forces to queue the data
which it is not able to send downwards.


Sebastian

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