Re: [Standards] Stanza Size Limits (was Re: [jdev] Communicate between two client instances of the same ID)
Justin Karneges wrote: On Tuesday 02 September 2008 21:47:55 Peter Saint-Andre wrote: http://www.xmpp.org/extensions/inbox/stanzalimits.html We never published that, though... Oh, cool. I was going to suggest a XEP for that stuff, too. :) I still think the minimum recommended supported size belongs in xmpp-core though. I've just added the following text to my working copy: ** 9.5. Stanza Size XMPP is optimized for the exchange of relatively large numbers of relatively small stanzas. A client or server MAY enforce a maximum stanza size. The maximum stanza size MUST NOT be smaller than 1 bytes, from the opening character to the closing character. If an entity receives a stanza that exceeds its maximum stanza size, it MUST return a not-acceptable/ stanza error or a policy-violation/ stream error. ** smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] Stanza Size Limits (was Re: [jdev] Communicate between two client instances of the same ID)
On Sep 4, 2008, at 12:16 PM, Fabio Forno wrote: On Wed, Sep 3, 2008 at 4:13 PM, Peter Saint-Andre [EMAIL PROTECTED] wrote: This would signal the client that the max stanza size is 65355 bytes, and the max allowed rate of stanzas per second is 10. I like that. What happens to your roster in that case? ;) Not only a joke. Some extensions like ibb can support any size limitations, but other stanzas like rosters, large data forms or pub sub events have no mechanisms for being split into several packets That limitation is Client = Server only. The subthread about Server = Client is still going strong: ) Best regards, -- Pedro Melo Blog: http://www.simplicidade.org/notes/ XMPP ID: [EMAIL PROTECTED] Use XMPP!
Re: [Standards] Stanza Size Limits (was Re: [jdev] Communicate between two client instances of the same ID)
On Sep 3, 2008, at 10:03 PM, Justin Karneges wrote: On Wednesday 03 September 2008 13:24:00 Pedro Melo wrote: On Sep 3, 2008, at 8:29 PM, Justin Karneges wrote: This is more of a server limit though. The client still needs a way to negotiate its own limit, and have the server protect the client from stanzas larger than that limit. ehe, Firewall XEP :). What if your own server breaks that limit, for example, sending you the roster? Peter would be in trouble... :) A hackish approach would be to make the roster iq-result exempt from limits. Long term, it's probably more appropriate to make the roster get sent as multiple stanzas if we wish to live by our stanzas should be small motto. Yeah, the work on incremental rosters. Servers already have Max stanza size on C2S and S2S. Do we really need more protection than that? If you set a small value for the server policy then you'd be fine, but that's not very flexible. For example, most desktop clients are surely capable of handling a 1MB stanza, but for some reason you cap your server at a much smaller 64KB. And even 64KB is probably too much for a mobile. So a flat maximum is not ideal. Sure but as a server admin I would not admit a client negotiating a larger stanza than my own C2S or S2S limits. So if the limits for the desktop client will likely be larger than those of [CS]2S, then there really is no need for this. I agree that mobile clients will want to cap the stanza limit, but this might be better end-to-end... Announce something via disco + IQ protocol. The server itself can use the same process to figure it out what the limit is and enforce it if likes. Each time we had a error back to the sender, we increase complexity on all the clients. And some stanzas are really hard to break in two... Sure, but you already have this problem with server-imposed limits. The fact is, we have these limits, because we believe stanzas should be of some reasonable size. All of our XEPs that may return large data must have a way of being split. That's just a fact of life. That's true. The limits are already there. /me ponders. I think a feature in disco#info plus a IQ-based protocol would be enough. Other entities (your own server, and other clients) can use the same protocol to obtain the limits you are willing to accept. Best regards, -- Pedro Melo Blog: http://www.simplicidade.org/notes/ XMPP ID: [EMAIL PROTECTED] Use XMPP!
Re: [Standards] Stanza Size Limits (was Re: [jdev] Communicate between two client instances of the same ID)
On Wed, Sep 3, 2008 at 11:15 PM, Pedro Melo [EMAIL PROTECTED] wrote: Sure but as a server admin I would not admit a client negotiating a larger stanza than my own C2S or S2S limits. Sorry - I'm jumping in mid-thread again, but I don't remember seeing this discussed. If stanza sizes are a stream feature, what's the work flow where one server wants to s2s with another server with a lower stanza size (given that its clients could be sending full-size stanzas)? /K
Re: [Standards] Stanza Size Limits (was Re: [jdev] Communicate between two client instances of the same ID)
Hi, On Sep 4, 2008, at 8:53 AM, Kevin Smith wrote: On Wed, Sep 3, 2008 at 11:15 PM, Pedro Melo [EMAIL PROTECTED] wrote: Sure but as a server admin I would not admit a client negotiating a larger stanza than my own C2S or S2S limits. Sorry - I'm jumping in mid-thread again, but I don't remember seeing this discussed. I was replying to this part of Justin email: If you set a small value for the server policy then you'd be fine, but that's not very flexible. For example, most desktop clients are surely capable of handling a 1MB stanza, but for some reason you cap your server at a much smaller 64KB. And even 64KB is probably too much for a mobile. So a flat maximum is not ideal. I interpreted that desktop clients have the capabilities of handling large stanzas. I was just clarifying that even if a client can perfectly handle large stanzas, I think that no server admin will allow a client to bypass their own rules. If stanza sizes are a stream feature, what's the work flow where one server wants to s2s with another server with a lower stanza size (given that its clients could be sending full-size stanzas)? Stanzas above the destination S2S limit will be rejected. This is like the Path MTU problems of IP. We where discussion last mile MTUs but those are only part of the problem, actually. I still like having something at the last mile, it prevents silly problems, but it wont avoid stanza-too-big errors. Path MTU is something that is important for IBB for example. Best regards, -- Pedro Melo Blog: http://www.simplicidade.org/notes/ XMPP ID: [EMAIL PROTECTED] Use XMPP!
Re: [Standards] Stanza Size Limits (was Re: [jdev] Communicate between two client instances of the same ID)
Kevin Smith wrote: On Wed, Sep 3, 2008 at 11:15 PM, Pedro Melo [EMAIL PROTECTED] wrote: Sure but as a server admin I would not admit a client negotiating a larger stanza than my own C2S or S2S limits. Sorry - I'm jumping in mid-thread again, but I don't remember seeing this discussed. If stanza sizes are a stream feature, what's the work flow where one server wants to s2s with another server with a lower stanza size (given that its clients could be sending full-size stanzas)? Gosh, do we really need all this complexity? Negotiating per-user limits seems unnecessary to me. /psa smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] Stanza Size Limits (was Re: [jdev] Communicate between two client instances of the same ID)
Fabio Forno wrote: On Wed, Sep 3, 2008 at 4:13 PM, Peter Saint-Andre [EMAIL PROTECTED] wrote: This would signal the client that the max stanza size is 65355 bytes, and the max allowed rate of stanzas per second is 10. I like that. /psa What happens to your roster in that case? ;) We need roster sequencing. And especially I do. :) So please provide some feedback on XEP-0237. Not only a joke. Some extensions like ibb can support any size limitations, but other stanzas like rosters, large data forms or pub sub events have no mechanisms for being split into several packets In current implementations (AFAIK), stanzas that you exchange directly with your server (e.g., roster, vCard) are exempt from the stanza size limits. But if you try to send a big stanza to someone else, the limit is enforced. Among other things, this means that you can upload a big vCard but if someone tries to retrieve it the request will fail. /psa smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] Stanza Size Limits (was Re: [jdev] Communicate between two client instances of the same ID)
Justin Karneges wrote: this enforcement is needed not because we need to protect the poor little client, but because if the client and server don't agree on the same value then it becomes super easy to DoS the client. All a remote user needs to do is send a message that is larger than the client max, but smaller than the server max. It is critical that the client and server agree on the same maximum value. Aha, now I see. Yes, this is critical. /psa smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] Stanza Size Limits (was Re: [jdev] Communicate between two client instances of the same ID)
On Sep 3, 2008, at 5:47 AM, Peter Saint-Andre wrote: Justin Karneges wrote: Dragging this over from jdev: Hmm. XMPP is not optimized for sending around 100k+ messages. Would 64KB chunks a reasonable thing to do? That's probably still too high. There is currently no specified maximum size for XMPP stanzas, but individual implementations may enforce different values. The original jabberd 1.0 server had around a 10KB maximum. The general consensus is that stanzas should be small, and this is largely in part because large stanzas block transmission of other stanzas (you cannot send many stanzas in parallel over one stream). Right now it's fuzzy as to how small you should chunk your data for maximum compatibility. I think we should define the largest stanza size that must be supported by clients and servers. We could just make this value 1 bytes, from the opening '' to the final '' of the stanza. The text should go into RFC 3920bis as a SHOULD. This way, stanzas 1 bytes or smaller are guaranteed to succeed in transmission. Stanzas larger than 1 bytes would still be transmittable, but without any guarantees that the other side will accept it (which is not any worse than the situation today). A question: which stanza error are we supposed to use to reject a stanza that is too large? Such an error would be very useful to determine the MTU. http://www.xmpp.org/extensions/inbox/stanzalimits.html Why not make section 3 a stream feature instead? Like: stream:features limits xmlns='urn:xmpp:tmp:stanza-limits' size65355/size rate10/rate /limits /stream:features This would signal the client that the max stanza size is 65355 bytes, and the max allowed rate of stanzas per second is 10. Other limits could be included also (max presence changes per time- period?) but at least size and rate seem important to me. Best regards, -- Pedro Melo Blog: http://www.simplicidade.org/notes/ XMPP ID: [EMAIL PROTECTED] Use XMPP!
Re: [Standards] Stanza Size Limits (was Re: [jdev] Communicate between two client instances of the same ID)
Justin Karneges wrote: On Tuesday 02 September 2008 21:47:55 Peter Saint-Andre wrote: http://www.xmpp.org/extensions/inbox/stanzalimits.html We never published that, though... Oh, cool. I was going to suggest a XEP for that stuff, too. :) Maybe the next Council will publish it. Or I can poke the Council about it in today's meeting (which is the last meeting of the current term). I still think the minimum recommended supported size belongs in xmpp-core though. Probably. But then people will complain that this kind of thing is a local service policy blah blah blah. :) /psa smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] Stanza Size Limits (was Re: [jdev] Communicate between two client instances of the same ID)
Pedro Melo wrote: On Sep 3, 2008, at 5:47 AM, Peter Saint-Andre wrote: Justin Karneges wrote: Dragging this over from jdev: Hmm. XMPP is not optimized for sending around 100k+ messages. Would 64KB chunks a reasonable thing to do? That's probably still too high. There is currently no specified maximum size for XMPP stanzas, but individual implementations may enforce different values. The original jabberd 1.0 server had around a 10KB maximum. The general consensus is that stanzas should be small, and this is largely in part because large stanzas block transmission of other stanzas (you cannot send many stanzas in parallel over one stream). Right now it's fuzzy as to how small you should chunk your data for maximum compatibility. I think we should define the largest stanza size that must be supported by clients and servers. We could just make this value 1 bytes, from the opening '' to the final '' of the stanza. The text should go into RFC 3920bis as a SHOULD. This way, stanzas 1 bytes or smaller are guaranteed to succeed in transmission. Stanzas larger than 1 bytes would still be transmittable, but without any guarantees that the other side will accept it (which is not any worse than the situation today). A question: which stanza error are we supposed to use to reject a stanza that is too large? Such an error would be very useful to determine the MTU. http://www.xmpp.org/extensions/inbox/stanzalimits.html Why not make section 3 a stream feature instead? Like: stream:features limits xmlns='urn:xmpp:tmp:stanza-limits' size65355/size rate10/rate /limits /stream:features This would signal the client that the max stanza size is 65355 bytes, and the max allowed rate of stanzas per second is 10. I like that. /psa smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] Stanza Size Limits (was Re: [jdev] Communicate between two client instances of the same ID)
On 3 Sep 2008, at 15:13, Peter Saint-Andre wrote: Pedro Melo wrote: On Sep 3, 2008, at 5:47 AM, Peter Saint-Andre wrote: Justin Karneges wrote: Dragging this over from jdev: Hmm. XMPP is not optimized for sending around 100k+ messages. Would 64KB chunks a reasonable thing to do? That's probably still too high. There is currently no specified maximum size for XMPP stanzas, but individual implementations may enforce different values. The original jabberd 1.0 server had around a 10KB maximum. The general consensus is that stanzas should be small, and this is largely in part because large stanzas block transmission of other stanzas (you cannot send many stanzas in parallel over one stream). Right now it's fuzzy as to how small you should chunk your data for maximum compatibility. I think we should define the largest stanza size that must be supported by clients and servers. We could just make this value 1 bytes, from the opening '' to the final '' of the stanza. The text should go into RFC 3920bis as a SHOULD. This way, stanzas 1 bytes or smaller are guaranteed to succeed in transmission. Stanzas larger than 1 bytes would still be transmittable, but without any guarantees that the other side will accept it (which is not any worse than the situation today). A question: which stanza error are we supposed to use to reject a stanza that is too large? Such an error would be very useful to determine the MTU. http://www.xmpp.org/extensions/inbox/stanzalimits.html Why not make section 3 a stream feature instead? Like: stream:features limits xmlns='urn:xmpp:tmp:stanza-limits' size65355/size rate10/rate /limits /stream:features This would signal the client that the max stanza size is 65355 bytes, and the max allowed rate of stanzas per second is 10. I like that. /psa +1 I like this too. The server can inform a client ahead of time what traffic limits are going to be enforced. Artur -- Artur Hefczyc http://www.tigase.org/ http://artur.hefczyc.net/
Re: [Standards] Stanza Size Limits (was Re: [jdev] Communicate between two client instances of the same ID)
Am 03.09.2008 um 21:29 schrieb Justin Karneges: This is more of a server limit though. The client still needs a way to negotiate its own limit, and have the server protect the client from stanzas larger than that limit. The client should be able to accept all sizes. Otherwise, I'm sure we will see clients someday that have a maximum size for stanzas and then have an internal buffer that is exactly that big, miss some boundary checking and tada, we have our buffer overflow. -- Jonathan PGP.sig Description: This is a digitally signed message part
Re: [Standards] Stanza Size Limits (was Re: [jdev] Communicate between two client instances of the same ID)
Hi, On Sep 3, 2008, at 8:29 PM, Justin Karneges wrote: On Wednesday 03 September 2008 10:07:09 Artur Hefczyc wrote: On 3 Sep 2008, at 15:13, Peter Saint-Andre wrote: Pedro Melo wrote: Why not make section 3 a stream feature instead? Like: stream:features limits xmlns='urn:xmpp:tmp:stanza-limits' size65355/size rate10/rate /limits /stream:features This would signal the client that the max stanza size is 65355 bytes, and the max allowed rate of stanzas per second is 10. I like that. /psa +1 I like this too. The server can inform a client ahead of time what traffic limits are going to be enforced. This is more of a server limit though. The client still needs a way to negotiate its own limit, and have the server protect the client from stanzas larger than that limit. ehe, Firewall XEP :). What if your own server breaks that limit, for example, sending you the roster? Peter would be in trouble... :) Are we really going for the ICMP can't fragment error road? Servers already have Max stanza size on C2S and S2S. Do we really need more protection than that? Each time we had a error back to the sender, we increase complexity on all the clients. And some stanzas are really hard to break in two... Best regards, -- Pedro Melo Blog: http://www.simplicidade.org/notes/ XMPP ID: [EMAIL PROTECTED] Use XMPP!
[Standards] Stanza Size Limits (was Re: [jdev] Communicate between two client instances of the same ID)
Dragging this over from jdev: Hmm. XMPP is not optimized for sending around 100k+ messages. Would 64KB chunks a reasonable thing to do? That's probably still too high. There is currently no specified maximum size for XMPP stanzas, but individual implementations may enforce different values. The original jabberd 1.0 server had around a 10KB maximum. The general consensus is that stanzas should be small, and this is largely in part because large stanzas block transmission of other stanzas (you cannot send many stanzas in parallel over one stream). Right now it's fuzzy as to how small you should chunk your data for maximum compatibility. I think we should define the largest stanza size that must be supported by clients and servers. We could just make this value 1 bytes, from the opening '' to the final '' of the stanza. The text should go into RFC 3920bis as a SHOULD. This way, stanzas 1 bytes or smaller are guaranteed to succeed in transmission. Stanzas larger than 1 bytes would still be transmittable, but without any guarantees that the other side will accept it (which is not any worse than the situation today). A question: which stanza error are we supposed to use to reject a stanza that is too large? Such an error would be very useful to determine the MTU. -Justin
Re: [Standards] Stanza Size Limits (was Re: [jdev] Communicate between two client instances of the same ID)
Justin Karneges wrote: Dragging this over from jdev: Hmm. XMPP is not optimized for sending around 100k+ messages. Would 64KB chunks a reasonable thing to do? That's probably still too high. There is currently no specified maximum size for XMPP stanzas, but individual implementations may enforce different values. The original jabberd 1.0 server had around a 10KB maximum. The general consensus is that stanzas should be small, and this is largely in part because large stanzas block transmission of other stanzas (you cannot send many stanzas in parallel over one stream). Right now it's fuzzy as to how small you should chunk your data for maximum compatibility. I think we should define the largest stanza size that must be supported by clients and servers. We could just make this value 1 bytes, from the opening '' to the final '' of the stanza. The text should go into RFC 3920bis as a SHOULD. This way, stanzas 1 bytes or smaller are guaranteed to succeed in transmission. Stanzas larger than 1 bytes would still be transmittable, but without any guarantees that the other side will accept it (which is not any worse than the situation today). A question: which stanza error are we supposed to use to reject a stanza that is too large? Such an error would be very useful to determine the MTU. http://www.xmpp.org/extensions/inbox/stanzalimits.html We never published that, though... /psa smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] Stanza Size Limits (was Re: [jdev] Communicate between two client instances of the same ID)
On Tuesday 02 September 2008 21:47:55 Peter Saint-Andre wrote: http://www.xmpp.org/extensions/inbox/stanzalimits.html We never published that, though... Oh, cool. I was going to suggest a XEP for that stuff, too. :) I still think the minimum recommended supported size belongs in xmpp-core though. -Justin
