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

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

Hi Hisham,

>>The support and use of the attribute/parameter would be 
>>OPTIONAL, so if a node doesn't support the 
>>attribute/parameter (it is not able to calculate a value, it 
>>can't be configured, or the node simply thinks that size 
>>doesn't matter) everything will still work, as today, and it 
>>will then be "local policy" what to do if the messages can't 
>>be handled.
> 
>So, You send me an offer with receive-max-size of 1500 bytes, 
>but I don't understand that parameter. This doesn't help you. 
>I send you a message with 1Meg and you have to reject it with 
>a 4xx anyway. So where is the benefit of having this as optional?

The benefit is that you may have scenarios or network architectures where this information is used (not only by the end terminals, but also by intermediate nodes) for making service/routing/etc decissions. Of course, a node may always send too large messages, which have to be rejected (using a 4xx response), but the idea is to have a mechanism where this can be avoided. If big messages are to be sent I think it is very useful to have this information, in order to adjust terminal settings, and to make the transmission smooth, and in order to send lots of stuff on the network that may be rejected (that data may then have to be retransmitted, using smaller messages, or the session may fail).

This is similar to any other SDP attribute. If you don't support it, you discard it, and things should work anyway - but IF you support it it may provide you with useful information for optimal performance.

However, IF people prefear making support mandatory, I personally don't have anything against that. But, that's not what I am proposing, because I do realize there may be scenarios where this kind of information is not needed. Another option is making it mandatory, and defining a default value if the information is not present (similar to the "sendrecv" media direction attribute), but that is not what I am proposing either. My issue is that I think it's useful to have this kind of information.

Regards,

Christer Holmberg
Ericsson Finland

> 
> /Hisham
> 
> > 
> > Of course, a node can send a 4xx response if the message it 
> > receives is too big, but as I said before, there may be 
> > scenarios where the size information is used to make 
> > decissions already at the session setup phase.
> > 
> > As Andrew said, this feature is especially useful for mobile 
> > devices, or other nodes with limited memory.
> > 
> > And, since there is a requirement at least for the receiving 
> > part, I assume it at some stage has been realized that the 
> > information could be useful.
> > 
> > Regards,
> > 
> > Christer Holmberg
> > Ericsson Finland
> > 
> > 
> > 
> > 
> > 
> > > -----Original Message-----
> > > From: Paul Kyzivat [mailto:[email-masked]]
> > > Sent: 7. kesäkuuta 2004 19:55
> > > To: Ben Campbell
> > > Cc: Chris Boulton; [email-masked]; 
> > > [email-masked]; Christer
> > > Holmberg (JO/LMF)
> > > Subject: Re: [Simple] Re: MSRP: Max message size indication
> > > 
> > > 
> > > Ben,
> > > 
> > > 
> > > 	Paul
> > > 
> > > 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 09:41:38 -0500

I don't want to get too deep in this until we have results on the "vote" 
(running neck and neck at the moment.) But to risk jumping into 
mechanism, comments inline:

> The benefit is that you may have scenarios or network architectures where this information is used (not only by the end terminals, but also by intermediate nodes) for making service/routing/etc dec…

If this is something we expect proxies to use for routing decisions, we 
should consider doing it in the headers, rather than in the body. So, is 
there anything in caller-prefs that will help here?