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

From: Sebastian Dehne <[email-masked]>
Date: Mon, 23 Jun 2008 11:39:02 +0200

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
[email-masked]
https://www.ietf.org/mailman/listinfo/simple

---

From: Ruud Klaver <[email-masked]>
Date: Thu, 26 Jun 2008 12:26:50 +0200

Hi,

> which it is not able to send downwards.

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?

Ruud Klaver
AG Projects

---

From: Sebastian Dehne <[email-masked]>
Date: Thu, 26 Jun 2008 14:21:34 +0200

> 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.
> 
> 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.
> 
> of the data to be sent to this slow client, which personally I would not 
> prefer to do.
> 
> 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

---

From: Ruud Klaver <[email-masked]>
Date: Mon, 30 Jun 2008 16:52:59 +0200

Hi Sebastian,

On 26 Jun 2008, at 14:21, Sebastian Dehne wrote:

>> 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  
> 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  
> 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

This indeed what I was thinking of. Glad to see we're on the same  
frequency ;)

In any case, as an implementer, this seems to be the most workable  
solution to me.

Ruud Klaver
AG Projects

---

From: Sebastian Dehne <[email-masked]>
Date: Mon, 30 Jun 2008 17:18:35 +0200

> In any case, as an implementer, this seems to be the most workable 

It would be nice to read this back in the simple-chat draft.

Sebastian