Subject: Re: [Simple] Re: MSRP: Max message size indication

From: Ben Campbell <[email-masked]>
Date: Mon, 07 Jun 2004 10:30:01 -0500

I'd like to try and get some closure on this:

Please answer yes or no to the following:

1) Should we add the optional signaling of the maximum content size you 
are willing to _receive_ into the SDP exchange.

2) Should we add the optional signaling of the maximum content size you 
are planning to _send_ into the SDP exchange.

3) If either 1 or 2 is yes, do we send one value for the session, or one 
value per each type for which we have indicated support.

My personal opinions:

No and No. In all honesty, I think this could be a useful feature, but I 
don't think MSRP has to have it to function. I am voting no, not because 
I disagree with the feature, but because I don't want to add additional 
work to completing MSRP unless it is absolutely necessary. But if 
consensus says we need it, I do not object on any technical basis.

Chris Boulton wrote:

> I think this feature would certainly be useful for max receive (if it was type specific) BUT I am not convinced about send.
>  
> Chris.
>  
> 
> 	-----Original Message----- 
> 	From: Ben Campbell [mailto:[email-masked]] 
> 	Sent: Tue 25/05/2004 18:27 
> 	To: Christer Holmberg (JO/LMF) 
> 	Cc: [email-masked]; [email-masked] 
> 	Subject: Re: [Simple] Re: MSRP: Max message size indication
> 	
> 	
> 
> 	Let me step up a level:
> 	
> 	By the required vs useful discussion, I was referring to the feature of
> 	being able to signal size limitations itself, rather than some aspect of
> 	the feature.
> 	
> 	So, what do others about whether the feature of being able to signal
> 	message size limits is required?
> 	
> 	Christer Holmberg (JO/LMF) wrote:
> 	
> 	> Hi,
> 	>
> 	>
> 	>>(Ignore my yet-another-empty reply. This time I blame the combined
> 	>>ergonomics of Thunderbird and my laptop.)
> 	>>
> 	>>That brings up an interesting meta-question. What is the bar
> 	>>for putting new features into MSRP at this stage? Is "useful" enough? Or
> 	>>should we limit new features to things that we decide are "required."
> 	>
> 	>
> 	> Well, the max-receive is required, and I think it is very useful. As I wrote earlier, the question is if it should be possible to indicate separate values for different media types.
> 	>
> 	> The max-send is not required, but I still think it would be very useful. Earlier I gave some examples I think are very valid (nodes may try to reserve memory according to how much big messages then can expect to receive, redirection/forking may be done based on the information etc etc etc). It wouldn't have any impacts on the protocol functionality itself, and there would be no interop problems with nodes that don't understand the max-send attribute/parameter (or just don't care about it).
> 	>
> 	> Regards,
> 	>
> 	> Christer Holmberg
> 	> Ericsson Finland
> 	>
> 	>
> 	>
> 	>>[email-masked] wrote:
> 	>>
> 	>>
> 	>>>I think max-receive is useful, but not max-send.
> 	>>>
> 	>>>/Hisham
> 	>>>
> 	>>>
> 	>>>
> 	>>>>-----Original Message-----
> 	>>>>From: [email-masked]
> 	>>>>[mailto:[email-masked]]On Behalf
> 	>>>>Of ext Ben Campbell
> 	>>>>Sent: 25.May.2004 17:49
> 	>>>>To: Christer Holmberg (JO/LMF)
> 	>>>>Cc: [email-masked]'
> 	>>>>Subject: [Simple] Re: MSRP: Max message size indication
> 	>>>>
> 	>>>>
> 	>>>>(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?
> 	>>
> 	>>>>
> 	>>>>
> 	>>>>Christer Holmberg (JO/LMF) wrote:
> 	>>>>
> 	>>>>
> 	>>>>
> 	>>>>>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
> 	>>>>
> 	>>
> 	
> 	
> 	_______________________________________________
> 	Simple mailing list
> 	[email-masked]
> 	https://www1.ietf.org/mailman/listinfo/simple
> 	
> 
> 
> 
> This message has been scanned for viruses by MailControl - www.mailcontrol.com
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Simple mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/simple

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

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 07 Jun 2004 12:55:26 -0400

Ben,

I'm inclined to agree with you (no/no). For many nodes this is simply 
not a number that is easily decided. If anything, I imagine it would be 
best to negotiate this. But that requires the sender to pick a maximum 
send value, even though the sender probably has no particular limit. 
This just seems like a rat hole best avoided for now.

	Paul

Ben Campbell wrote:
>> I think this feature would certainly be useful for max receive (if it 
>> was type specific) BUT I am not convinced about send.
>>  
>> Chris.
>>  
>>
>>     -----Original Message-----     From: Ben Campbell 
>> [mailto:[email-masked]]     Sent: Tue 25/05/2004 18:27 
>>     To: Christer Holmberg (JO/LMF)     Cc: [email-masked]; 
>> [email-masked]     Subject: Re: [Simple] Re: MSRP: Max message size 
>> indication
>>     
>>     
>>
>>     Let me step up a level:
>>     
>>     > Well, the max-receive is required, and I think it is very 
>> useful. As I wrote earlier, the question is if it should be possible 
>> to indicate separate values for different media types.
>>     >
>>     > The max-send is not required, but I still think it would be very 
>> useful. Earlier I gave some examples I think are very valid (nodes may 
>> try to reserve memory according to how much big messages then can 
>> expect to receive, redirection/forking may be done based on the 
>> information etc etc etc). It wouldn't have any impacts on the protocol 
>> functionality itself, and there would be no interop problems with 
>> nodes that don't understand the max-send attribute/parameter (or just 
>> don't care about it).
>>     >
>>     > Regards,
>>     >
>>     > Christer Holmberg
>>     > Ericsson Finland
>>     >
>>     >
>>     >

---

From: Aki Niemi <[email-masked]>
Date: Tue, 08 Jun 2004 19:31:48 +0300

I'll have to vote for no/no. I don't think it solves the real problem,
which is not having the sender/recipient ability to abort transfer
mid-message.

Cheers,
Aki

---

From: Ben Campbell <[email-masked]>
Date: Tue, 08 Jun 2004 12:46:10 -0500

So far, I have had 4 people (counting myself) respond no/no, 2 respond 
yes/yes, and one equivocation that I interpret as yes/no.

This is a pretty small fraction of the work group. If only seven people 
care enough to even comment, I'm not sure we have a mandate for this.

So, if there is anyone out there who cares but has not said so, please 
do so soon.

---

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 08 Jun 2004 22:28:01 +0300

Ben,

> Since we have a written requirement, I propose we move forward with "max 
> I am willing to receive" part, but not "the max I intend to send" part.

Given that what you are proposing is the simplest way to meet the 
requirement (i.e., the proposal complays with the KISS rule), I agree 
that this is the way forward.

Thanks,

Gonzalo

---

From: Ben Campbell <[email-masked]>
Date: Tue, 08 Jun 2004 14:21:17 -0500

Gonzalo Camarillo wrote:

> Ben,
> 
> let me try to understand the discussion here. We have a requirements 
> document (written by Jonathan) that says the following:
> 
> http://www.ietf.org/internet-drafts/draft-rosenberg-simple-messaging-requirements-01.txt 
> 
> 
>    "REQ-CONTENT-1: A UA MUST be able to indicate the maximum message
>       size it is willing to receive."
> 
> According to the requirements, the protocol MUST support it... do you 
> want to go through the requirements phase again at this point?

Ah, I missed making that connection. Avoiding the question of which came 
first (agreed upon MSRP requirements and that document) for the moment, 
this would seem to support the yes/no vote. (That is, ability to express 
max you are willing to receive vs max you intend to send.)

>> This is a pretty small fraction of the work group. If only seven 
>> people care enough to even comment, I'm not sure we have a mandate for 
>> this.
>>
>>>> 1) Should we add the optional signaling of the maximum content size 
>>>> you are willing to _receive_ into the SDP exchange.
>>>>
>>>> 2) Should we add the optional signaling of the maximum content size 
>>>> you are planning to _send_ into the SDP exchange.
>>>>
>>>> 3) If either 1 or 2 is yes, do we send one value for the session, or 
>>>> one value per each type for which we have indicated support.
>>>>
>>>> My personal opinions:
>>>>
>>>> No and No. In all honesty, I think this could be a useful feature, 
>>>> but I don't think MSRP has to have it to function. I am voting no, 
>>>> not because I disagree with the feature, but because I don't want to 
>>>> add additional work to completing MSRP unless it is absolutely 
>>>> necessary. But if consensus says we need it, I do not object on any 
>>>> technical basis.
>>>
>>>

---

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 08 Jun 2004 22:13:35 +0300

Ben,

Gonzalo