Subject: RE: MESSAGE size limitations (Was: RE: [Sip] Message draft changes)

From: [email-masked]
Date: Mon, 20 May 2002 17:18:26 +0300

> Would you expect the MESSAGE draft to stall waiting for a 3261 fix? 

If you're talking about another draft-ietf-sip-rfc3261bis cycle, certainly not.

But (a) since RFC 3261 hasn't actually been published yet, I imagine a "fix" could sneak in even in such a late stage. Of course not being that familiar with the IETF process this may be daydreaming, but I was under the impression that even though undesireable, changes may be considered even to documents that have been approved by the IESG.

Another issue is, that (b) would a fix such as the one described by the post below actually properly fulfill the requirements for congestion control of MESSAGEs.

If both (a) and (b) aren't going to be reality, I will shut my mouth for now, save my comments for whichever documents will update the protocol in the future, and be perfectly happy with #1, as long as the text is aligned with bis-09 on the relevant parts.

Cheers,
Aki

> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]
> > Sent: Monday, May 20, 2002 4:13 AM
> > To: [email-masked]; [email-masked]; [email-masked];
> > [email-masked]; [email-masked]; 
> [email-masked]
> > Cc: [email-masked]
> > Subject: RE: MESSAGE size limitations (Was: RE: [Sip] Message draft
> > changes)
> > 
> > 
> > Hi,
> > 
> > If #2 is in any way possible, let's pursue that. Reading the 
> > bis-09 again, I can't help but wonder if the RFC2543 option of 
> > still trying with UDP, if TCP has failed actually provides value 
> > for messages over the UDP maximum datagram size of 65,535 bytes.
> > 
> > If there was a SHOULD in trying UDP when TCP fails, but a SHOULD 
> > NOT if size is over 65k, would the MESSAGE then be more well 
> > behaved? I.e., enough to be able to relax the size limit to a 
> > SHOULD strength in the message draft?
> > 
> > Otherwise, I'm ready to live with #2, given that the text is 
> > changed to align with bis-09 (MESSAGE talks about payload size, 
> > whereas bis-09 talks about request size), and provide with a way 
> > to send larger messages if there is a transport with congestion 
> > control all the way to the destination.
> > 
> > Cheers,
> > Aki
> > 
> >  
> > 
> > > -----Original Message-----
> > > From: ext Ben Campbell [mailto:[email-masked]]
> > > Sent: Saturday, May 18, 2002 12:17 AM
> > > To: Henning Schulzrinne; Michael Thomas; Dean Willis; 'Jonathan
> > > Rosenberg'; 'Sean Olson'; Niemi Aki (NET/Espoo)
> > > Cc: [email-masked]
> > > Subject: RE: MESSAGE size limitations (Was: RE: [Sip] 
> Message draft
> > > changes)
> > > 
> > > 
> > > OK, to summarize where I think we are, I have seen 4 
> > > proposals for dealing
> > > with the message size controversy:
> > > 
> > > 1) Just live with it. IM's are not designed to carry large 
> > > content anyway.
> > > Large content should be sent using some other mechanism, like 
> > > in-session
> > > messages, content indirection, or something completely 
> > > different like email.
> > > (bottom line: limit stays, with perhaps a clarification of 
> > > the how the limit
> > > relates to the lowest hop MTU.)
> > > 
> > > 2) Fix the SIP "feature" that creates this problem in the 
> > > first place, i.e.
> > > the fact that a proxy can fail over to UDP even when a 
> > > congestion controlled
> > > transport is requested. Jonathan suggested dissallowing this 
> > > proxy behavior
> > > for large content messages. I'm not sure how hard that charge 
> > > would be to
> > > get into 3261.
> > > 
> > > 3) Adding something like a proxy-require:contestion-safe tag, 
> > > so that the
> > > UAC can insist on end-to-end congestion control. This of 
> > > course means that
> > > large content MESSAGE requests could not pass _any_ existing 
> > > proxies--but
> > > that is no more limiting than saying you can't have large 
> > > content messages
> > > at all. It at least gives us a way to relax the limit if we 
> > > someday do get
> > > proxies that support the tag.
> > > 
> > > 4) Relax the limit back to a should, but take no further 
> > > action. I do not
> > > think that would pass IESG muster at this point.
> > > 
> > > Personally I lean towards option 1. Pager model IMs are 
> really _not_
> > > intended to be a file transfer mechanism. Even without a 
> > > strict limit, I
> > > think that large content messages (where content is 
> > > physically carried in
> > > the message) are a misuse of the mechanism. We should work to 
> > > specify an
> > > indirect-content mechanism, a session based mechanism, or 
> > > both. But those
> > > are out of scope for pager model messaging, and should 
> not become a
> > > dependency for this draft. Option 4 is pretty much out of the 
> > > question. 2 &
> > > 3 may be doable, but are significant enough that we might 
> > > need to re-cycle
> > > the last call.
> > > 
> > > This really seems to be a full circle discussion, back to 
> > > IMPP requirements
> > > days. I think our best bet is to narrow the scope to something
> > > solveable--that is short text (or otherwise small content) 
> > > instant messages,
> > > solve that, then work on more sophisticated mechanisms for 
> > > large content.
> > > 
> > > Thoughts?
> > > 
> > > > -----Original Message-----
> > > > From: Henning Schulzrinne [mailto:[email-masked]]
> > > > Sent: Friday, May 17, 2002 2:51 PM
> > > > To: Michael Thomas
> > > > Cc: Dean Willis; 'Jonathan Rosenberg'; 'Sean Olson'; 
> 'Ben Campbell';
> > > > [email-masked]; [email-masked]
> > > > Subject: Re: MESSAGE size limitations (Was: RE: [Sip] 
> Message draft
> > > > changes)
> > > >
> > > >
> > > > Joking aside, this may not be such a bad idea: Send an IM 
> > > with a message
> > > > reference, with email sent simultaneously. Generally, mail 
> > > delivery is
> > > > measured in seconds (and for the long messages we're 
> > > talking about here,
> > > > any processing delays would tend to be overwhelmed by 
> > > transport delays).
> > > > Avoids all firewall, cable modem restriction and NAT 
> issues and, to
> > > > boot, leverages off the likelihood that SIP and SMTP 
> address are the
> > > > same. Plus, with IMAP, the client already gets to 
> decide whether to
> > > > download attachments or not.
> > > >
> > > > Michael Thomas wrote:
> > > > > Dean Willis writes:
> > > > >  >
> > > > >  > One must ask -- at what point should one 
> transition from IM to
> > > > >  > email?
> > > > >
> > > > >    Immediately?
> > > 
> > > 
> 

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: [email-masked]
Date: Mon, 20 May 2002 18:10:41 +0300

Hi,

> bis-09 again, I can't help but wonder if the RFC2543 option 
> of still trying with UDP, if TCP has failed actually provides 
> value for messages over the UDP maximum datagram size of 65,535 bytes.
> 
> If there was a SHOULD in trying UDP when TCP fails, but a 
> SHOULD NOT if size is over 65k, would the MESSAGE then be 
> more well behaved? I.e., enough to be able to relax the size 
> limit to a SHOULD strength in the message draft?
> 
                                    ^^

Here, I meant to say of course that #1 is all right by me. Sorry for the mixup ;)

> changed to align with bis-09 (MESSAGE talks about payload 
> size, whereas bis-09 talks about request size), and provide 
> with a way to send larger messages if there is a transport 
> with congestion control all the way to the destination.
> 
> Cheers,
> Aki
> 
>  
> 
> > Personally I lean towards option 1. Pager model IMs are really _not_
> > are out of scope for pager model messaging, and should not become a
> > > Cc: Dean Willis; 'Jonathan Rosenberg'; 'Sean Olson'; 'Ben 
> Campbell';
> > > same. Plus, with IMAP, the client already gets to decide 
> whether to
> > > >  > One must ask -- at what point should one transition 
> from IM to
> > > >  > email?
> > > >
> > > >    Immediately?
> > 
> > 
>