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

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Tue, 8 Jun 2004 20:41:14 +0200

Hi Ben,

If for no other reason (ie if nobody thinks the usage examples I've given are valid), I think the requirement (REQ-CONTENT-1) is the "mandate" we need. Or, have I missunderstood the requirment? Of course the meaning of the requirement could be that one should be able to indicate the size in an error response, but the text about offer/answer, and that negotiation is needed , at least to me sounds that negotiation is what it's really about.

Now, of course, if there are technical reasons and/or big problems why a requirement can not be fullfilled we need to re-visit the requirments, and possibly change/remove something. But, so far most of the comments have been about that fact that this doesn't solve the issue when messages need to be rejected. However, the max-size attribute is not supposed to solve that issue, and the requirment says nothing about that issue, so I don't see why we should remove a requirement just because it doesn't solve something it's not even supposed to solve...

If we remove requirements just becuase we suddenly don't think they are needed I wonder how much work we have put on the requirements in the first place, especially when we have came this far with the actual protocol. 

HOWEVER, I would really not like to use the requirements as an argument, and I really hope we all think we have stable requirements - instead I have tried to describe the technical reasons why I think this would be useful.

Regards,

Christer Holmberg
Ericsson Finland

> -----Original Message-----
> From: Ben Campbell [mailto:[email-masked]]
> Sent: 8. kesäkuuta 2004 20:46
> To: Aki Niemi
> Cc: Chris Boulton; [email-masked]; 
> [email-masked]; Christer
> Holmberg (JO/LMF)
> Subject: Re: [Simple] Re: MSRP: Max message size indication
> 
> 
> 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.
> 
> Aki Niemi wrote:
> 
> > 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
> > 
> > On Mon, 2004-06-07 at 18:30, ext Ben Campbell wrote:
> > 
> >>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

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

---

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

I just replied to a similar comment from Gonzalo. I had forgotten about 
that requirement in the draft. That requirement seems to me to require 
being able to indicate the max size you are willing to receive. It does 
not seem to require indicating the max size you intend to send.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 09 Jun 2004 07:09:00 -0400

I havent been following this discussion entirely, but here is my input.

The requirement in the requirements document is strictly talking about 
indicating the maximum an endpoint is willing to receive. The primary 
purpose of this is for devices like mobile handsets, which want to be 
able to tell a peer "hey, don't send a huge image, I don't want to pay 
for that". I think its better to indicate this during the sdp exchange, 
rather than have the mobile cut off an incoming messages once it reaches 
that limit.

-Jonathan R.

Ben Campbell wrote:

>> If for no other reason (ie if nobody thinks the usage examples I've 
>> given are valid), I think the requirement (REQ-CONTENT-1) is the 
>> "mandate" we need. Or, have I missunderstood the requirment? Of course 
>> the meaning of the requirement could be that one should be able to 
>> indicate the size in an error response, but the text about 
>> offer/answer, and that negotiation is needed , at least to me sounds 
>> that negotiation is what it's really about.
>>
>> Now, of course, if there are technical reasons and/or big problems why 
>> a requirement can not be fullfilled we need to re-visit the 
>> requirments, and possibly change/remove something. But, so far most of 
>> the comments have been about that fact that this doesn't solve the 
>> issue when messages need to be rejected. However, the max-size 
>> attribute is not supposed to solve that issue, and the requirment says 
>> nothing about that issue, so I don't see why we should remove a 
>> requirement just because it doesn't solve something it's not even 
>> supposed to solve...
>>
>> If we remove requirements just becuase we suddenly don't think they 
>> are needed I wonder how much work we have put on the requirements in 
>> the first place, especially when we have came this far with the actual 
>> protocol.
>> HOWEVER, I would really not like to use the requirements as an 
>> argument, and I really hope we all think we have stable requirements - 
>> instead I have tried to describe the technical reasons why I think 
>> this would be useful.
>>
>> Regards,
>>
>> Christer Holmberg
>> Ericsson Finland
>>
>>
>>
>>
>>
>>> Cc: Chris Boulton; [email-masked]; [email-masked]; Christer
>>> Holmberg (JO/LMF)
>>> 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.
>>>
>>> Aki Niemi wrote:
>>>
>>>
>>>>>>     -----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:
>>>>>>     
>>> very useful. As I wrote earlier, the question is if it should be 
>>> possible to indicate separate values for different media types.
>>>
>>>>>>     >
>>> 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 

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com