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

From: [email-masked]
Date: Tue, 8 Jun 2004 17:36:03 +0300

Furthermore. If my terminal has 10Meg free memory and some logic decides that my IM session application gets 10% of that (1 Meg), so I signal max-receive-size of 1 Meg.

In the mean time, I have downloaded a 9 Meg mpeg from some sight. My quota for IMS session would now change to 100K. Do I resignal that max-receive-size has changed?

Also, after I have signalled that the max-receive-size is 1Meg, I receive a 1 Meg message and I accept it (since it did not exceed the 1Meg max size limit). Then I receive a second one of those 1 Meg messages, do I accept?

What does max-receive-size really mean? Max size of messages in total in this session? Max size of 1 message? How can I ever possibly determine the maximum message size I can receive is? In any case, rejecting a message because of size needs to be supported.

Too many questions, too little time -> I vote no/no (not as a chair)

/Hisham

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]On Behalf
> Of ext Drage, Keith (Keith)
> Sent: 08.June.2004 16:51
> To: Christer Holmberg (JO/LMF)
> Cc: [email-masked]
> Subject: RE: [Simple] Re: MSRP: Max message size indication
> 
> 
> Arguing that it is optional does not mean it should go into 
> an RFC with issues attached. We have to solve all the issues 
> even for optional capabilities, and even with restrictions, 
> to be be adopted, it must still be useful.
> 
> Our concern on this is that while a message receiver may know 
> the maximum size messages it can buffer, any message sender 
> would require an interaction with the use of the application 
> to decide what that maximum might be. In most, if not all 
> message sessions, that sending size might not be known until 
> the time it is required to send a message, and the overflow 
> may possibly not be known until the sender has started 
> sending the message.
> 
> Thus I see some need by the receiver of a message to abort a 
> message when the internal buffers get full. What happens then 
> - we still need to deal with this case even if a size is 
> negotiated. My assumption is that an application would do the 
> best to render what it has, accompanied by some meaningful 
> notation. Further recovery would then take place at the 
> application layer, e.g. a reply message saying "send your 
> message again without the picture because it was too big for 
> my receiver to handle". 
> 
> Now give that we have to do that anyway, do we gain any 
> advantage in the few cases where the future message size is 
> known at session establishment time.
> 
> regards
> 
> Keith
> 
> > -----Original Message-----
> > From: Christer Holmberg (JO/LMF) 
> > [mailto:[email-masked]]
> > Sent: 07 June 2004 18:23
> > To: 'Paul Kyzivat'; Ben Campbell
> > Cc: [email-masked]; Chris Boulton; [email-masked]
> > Subject: RE: [Simple] Re: MSRP: Max message size indication
> > 
> > 
> > 
> > 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
> > 
> 
> _______________________________________________
> 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: Alex Audu <[email-masked]>
Date: Wed, 09 Jun 2004 13:07:09 -0500

I think there is great value in  end-point being able to signal the 
maximum size of data it is
willing /able to accept at a time. This information could be used by the 
sender to, for example
send a less memory intensive version of say an image, instead of a full 
blown memory hungry
version.  This will allow the information to be communicated with a 
decreased risk of truncation
at first try. That makes for a more efficient communication (than 
without this feature).

I don't see the need  to signal max-send size.   So I vote yes/no

Cheers,
Alex.