[Standards] s2s blocking of abusive users

[Jesus Cea]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Tomasz Sterna wrote:
> Dnia 28-11-2007, Śr o godzinie 01:05 +0100, Jesus Cea pisze:
>>> The TCP buffering, timeouts and retransmission will handle the rest,
>>> thus you will effectively enforce the peer to transmit no faster
>> than
>>> 10kbps.
>> Then you add "lag" to the connection, but you will "eat" the bytes
>> sonner or later :-/
> 
> TCP buffers are not infinite and congestion control kicks very soon and
> takes care of excessive bytes.
> 
> Wikipedia has some good articles of it. Please read
> http://en.wikipedia.org/wiki/TCP_congestion_avoidance_algorithm

All traffic between two xmpp servers is transmitted using a single TCP
connection. You can't "delay" a single remote user. You "delay" all of them.

About your objection, I don't know what xmpp implementations are doing
when network buffering fills. They could cut the connection by timeout
or could enqueue (in application space) until exhausting RAM and hitting
the swap :-), finally crashing. We have no idea.

In fact, if I would program a xmpp server, I would enqueue in RAM and
cut the connection when buffer >X MB or I'm unable to flush the buffer
after Y seconds.

In some circunstances the server simply can't choose to not generate new
traffic. Let's say, I'm a user sending "normal" traffic to two other
users. One of them is receiving just fine. The other one annnounces a
closed TCP window (closed flow control) to the server, so traffic in
being enqueued in tcp layer and, later, in the application. Server
shouldn't block me, because that would impact my "normal" traffic with
the responsive user.

So flow control at TCP layer is of no help to the server. And less so
when the stream coming is multiplexing traffic by several different
(innocent) users. That is the case for S2S connections.

I think stpeter is talking more in the line of "I'm receiving abusing
traffic from XX at YYYY. I don't want to punish ALL @YYYY users. I rather
prefer to send a control stanza to @YYYY server asking for banning
XX at YYYY traffic to me, giving a reason". The @YYYY server could sent to
XX at YYYY user an inmediate notification message for each sending try,
like currently we do with the offline message storing (but these
notifications would be sended by the @YYYY server, not the remote one),
dropping the messages locally.

So, no TCP queues or delays to care of.

- --
Jesus Cea Avion                         _/_/      _/_/_/        _/_/_/
jcea at argo.es http://www.argo.es/~jcea/ _/_/    _/_/  _/_/    _/_/  _/_/
jabber / xmpp:jcea at jabber.org         _/_/    _/_/          _/_/_/_/_/
                               _/_/  _/_/    _/_/          _/_/  _/_/
"Things are not so easy"      _/_/  _/_/    _/_/  _/_/    _/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/        _/_/_/      _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQCVAwUBR1Vxxplgi5GaxT1NAQKk0QP+PdUHez0hzjhu/0Es6GcSeLFN4HW3anwy
yoW3Ax2CXkifdED1pc/2LeBcoKcm1VzP/+tEWuCeLQE/e9+o7wTlpPd6TMuaKzCd
OfU1W6LzDl3oqJ7gKCZuJz4JS3ViujAymUyUvy651I1WltZIV9uqADucaPtkM1in
zLLU0eVSR8U=
=V4+y
-----END PGP SIGNATURE-----