Subject: [Simple] MSRP: Max message size indication

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Mon, 24 May 2004 20:02:17 +0200

Hi,

As agreed at the SIMPLE interim meeting MSRP discussion I am bringing to the list the issue about being able to indicate the max content size a node is able to receive. Also, as input, in chapter 4 of draft-rosenberg-simple-messaging-requirements-01.txt there is a requirement for such functionality:

REQ-CONTENT-1: A UA MUST be able to indicate the maximum message size it is willing to receive. 

I think it would be useful if clients could indicate the maximum payload size he is able to receive, and also send, either per type or stream. Note that I am talking about the total message/content size, not the size of individual fragments (the spec does say that messages bigger than 2k should be fragmented).

If the max size is dependent on the media type, max size could be defined as a accept-type token paramter:

example:

accept-type: X;max-send=1000;max-receive=1000, Y;max-send=2000;max-receive=500

And, if the message size it not type dependent, generic max size attributes could be used.

example:

a=max-send: 1000
a=max-receive:1000

Even if one is not going to send more than the other party indicates he is able to receive I still think it is important that a node can indicate how much he is able to send. For example, the remote node may reserve memory according to that information, and/or intermediate proxies may do forking/routing based on the client capabilities.

An MSRP "message size too big" error code could also be useful, if a node for whatever reason is not able to accept a SEND message. This may be due to that the remote node is sending more data than was agreed in the offer/answer, but also due to that the receiving node for a short period isn't able to receive the agreed data size (if the max size change is permanent a new offer should of course be sent, instead of sending an error reply to every SEND). At the interim meeting is was desired to have a mechanism to "interrupt" the receival of a message, and this error code could be used to indicate that. The sender would then stop sending the message, and any possible yet unsent fragments.

Regards,

Christer Holmberg
Ericsson Finland

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Ben Campbell <[email-masked]>
Date: Tue, 25 May 2004 09:45:43 -0500

---

From: Ben Campbell <[email-masked]>
Date: Tue, 25 May 2004 09:48:52 -0500

(Oops, itchy trigger finger--ignore my last mail on the subject.)

I do not have strong feelings on this as a requirement. If we do want to 
do it, the general approach seems good at the first read, anyway. I 
don't think there is a need for the non-type specific size attribute. 
The only advantage would be to reduce size of the SDP. I don't see that 
as a big requirement, since it normally only happens one per session.

Do others have thoughts on the matter? Do we need this feature at all?