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

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Mon, 7 Jun 2004 19:22:50 +0200

Hi,

I disagree, and my answer is yes/yes.

>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.

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.

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: Paul Kyzivat <[email-masked]>
Date: Mon, 07 Jun 2004 14:08:00 -0400

You say this is all optional. But then you say that some nodes will make 
use of sender maximum size to allocate resources on the receiving node. 
So what happens when the sender doesn't specify?

1) sender specifies nothing, receiver assumes worst case.
    (The most it could possibly receive.) How is this
    better than doing nothing?

2) sender specifies nothing, receiver picks something
    less than worst case. Then there are things the
    sender won't be able to send that could have been
    sent had the sender requested so in advance. Not nice.

I'm not opposed to investigating it further. But I do agree with Ben 
that it is likely to slow things down. And if you intend for it to be 
optional then it should be no problem to add later.

	Paul