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

From: [email-masked]
Date: Mon, 20 May 2002 12:13:24 +0300

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: "Ben Campbell" <[email-masked]>
Date: Mon, 20 May 2002 08:16:19 -0500

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

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 21 May 2002 03:28:20 -0400

[email-masked] wrote:
> 
> 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.

Well, to be honest, there are other reasons why sending such large
content (over 64k) in SIP directly is a bad idea in any case, TCP or no
TCP. I can't tell you how many times I've flamed people for sending 10M
email attachments to mailing lists; I always prefer a URL so that I can
fetch it at my convenience. 

MMS in the GSM world works the same; everything is via indirection.

My concern is actually with the arbitraryness of the 1300 number; I fear
there will be cases when an indirection might even exceed this limit (in
the case of S/MIME with a cert chain). Last thing we want to do is
discourage S/MIME usage...

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email-masked]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com