[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Simple] Flood control in the msrp-switch
Hi Sebastian,
On 26 Jun 2008, at 14:21, Sebastian Dehne wrote:
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 begFrom simple-bounces at ietf.org Mon Jun 30 07:53:01 2008
Return-Path: <simple-bounces at ietf.org>
X-Original-To: simple-archive at megatron.ietf.org
Delivered-To: ietfarch-simple-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id F09823A6A1A;
Mon, 30 Jun 2008 07:53:00 -0700 (PDT)
X-Original-To: simple at core3.amsl.com
Delivered-To: simple at core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 386B83A6A40
for <simple at core3.amsl.com>; Mon, 30 Jun 2008 07:53:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.117
X-Spam-Level:
X-Spam-Status: No, score=-1.117 tagged_above=-999 required=5
tests=[BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482]
Received: from mail.ietf.org ([64.170.98.32])
by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id 1T8jYYKRS4UZ for <simple at core3.amsl.com>;
Mon, 30 Jun 2008 07:52:59 -0700 (PDT)
Received: from node05.dns-hosting.info (node05.dns-hosting.info [85.17.186.5])
by core3.amsl.com (Postfix) with ESMTP id 1B46F3A6819
for <simple at ietf.org>; Mon, 30 Jun 2008 07:52:58 -0700 (PDT)
Received: from mit.xs4all.nl ([80.101.96.20] helo=[192.168.1.127])
by node05.dns-hosting.info with esmtpsa
(TLS-1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.68)
(envelope-from <ruud at ag-projects.com>) id 1KDKj3-00072b-JC
for simple at ietf.org; Mon, 30 Jun 2008 16:51:31 +0200
Message-Id: <B1334299-85A5-49C4-92B1-13531FDC2989 at ag-projects.com>
From: Ruud Klaver <ruud at ag-projects.com>
To: simple at ietf.org
In-Reply-To: <486389CE.7030908 at colibria.com>
Mime-Version: 1.0 (Apple Message framework v924)
Date: Mon, 30 Jun 2008 16:52:59 +0200
References: <485F6F36.7060104 at colibria.com>
<105FB5B5-5E04-4616-B8B9-2B6C613B3626 at ag-projects.com>
<486389CE.7030908 at colibria.com>
X-Mailer: Apple Mail (2.924)
X-SA-Exim-Connect-IP: 80.101.96.20
X-SA-Exim-Mail-From: ruud at ag-projects.com
X-SA-Exim-Version: 4.2.1 (built Tue, 21 Aug 2007 23:39:36 +0000)
X-SA-Exim-Scanned: Yes (on node05.dns-hosting.info)
Subject: Re: [Simple] Flood control in the msrp-switch
X-BeenThere: simple at ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
<simple.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/simple>,
<mailto:simple-request at ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/simple>
List-Post: <mailto:simple at ietf.org>
List-Help: <mailto:simple-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/simple>,
<mailto:simple-request at ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes"
Sender: simple-bounces at ietf.org
Errors-To: simple-bounces at ietf.org
Hi Sebastian,
On 26 Jun 2008, at 14:21, Sebastian Dehne wrote:
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 dreamin 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
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
_______________________________________________
Simple mailing list
Simple at ietf.org
https://www.ietf.org/mailman/listinfo/simple
ing 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
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
_______________________________________________
Simple mailing list
Simple at ietf.org
https://www.ietf.org/mailman/listinfo/simple