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

From: [email-masked]
Date: Thu, 16 May 2002 17:46:55 +0300

Hi,

Comments inline.

> > Since it is totally possible to send the MESSAGE directly to the
> > recipient (R-URI points to the interface address directly, not
> > the AOR), doesn't the sender in this case have definite
> > knowledge, that the hop will use TCP? The MUST strength forces
> > the UA to *always* follow the fixed 1300 limit.
> >
> > I'm sure there are also other cases, where UDP hops will
> > definitely not exist. I'm wondering if the congestion control
> > could do away with some SHOULD based construct on the size
> > limitation? The MUST really limits the features of IM, in 
> my opinion.
> 
> We had it as a SHOULD before, and were asked to change it. It might be
> possible to change it to say you MUST NOT exceed 1300 bytes 
> unless you have
> affirmative knowledge that no hop along the way will use UDP. But that
> limits you to some pretty trivial uses in the pager model.

I wish I had a piece of text to suggest that would satisfy this, but I don't. I understand that there may be a non-bis09 compatible proxy out there despite the suggestions made about the congestion control in the MESSAGE draft. But still, fixing a maximum size of 1300 bytes for IM seems to me, if you don't mind my saying ;), a hack. Sort of like the one that limited SMSs to be only 160 characters long...

> > > There is work underway to define a mechanism for indirect
> > > content. I think
> > > we will have to use that for any sort of large content.
> >
> > I'm aware of that work. The problem is that it is still in a
> > concept level only. Even though it looks like a trivially
> > solvable problem, discussions on the requirements in the interim
> > meeting suggested that there are some tricky issues to it, too.
> > I'm not buying this argument until there's at least a WG item for
> > a solution.
> 
> I agree it is not trivial, but it is doable. I think we are 
> in process of
> getting a wg item for this in SIMPLE. We _do_ have a wg item 
> for message
> sessions in SIMPLE, which would be another possible solution.

In my opinion, the message session won't work well enough. The user experience in the session model is inherently different to the paging model. Receiving an INVITE should indicate that there exists a desire to establish a conversation. Likewise, accepting the INVITE should indicate that the party is willing to commit to the conversation, however brief it may end up being. But if the reason for establishing the session was actually to circumvent some transport inefficiency, this user experience factor is lost.

Regards,
Aki

_______________________________________________
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: Thu, 16 May 2002 10:05:51 -0500

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, May 16, 2002 9:47 AM
> To: [email-masked]; [email-masked]
> Subject: RE: MESSAGE size limitations (Was: RE: [Sip] Message draft
> changes)
>
>

{snip}

>
> I wish I had a piece of text to suggest that would satisfy this,
> but I don't. I understand that there may be a non-bis09
> compatible proxy out there despite the suggestions made about the
> congestion control in the MESSAGE draft. But still, fixing a
> maximum size of 1300 bytes for IM seems to me, if you don't mind
> my saying ;), a hack. Sort of like the one that limited SMSs to
> be only 160 characters long...

I certainly don't mind you saying it :-).

The problem is not just pre-bis proxies, btw. If I understand correctly,
even a bis proxy can choose to switch to UDP if it cannot reach the next hop
via TCP. A general fix might lie there.

>
> In my opinion, the message session won't work well enough. The
> user experience in the session model is inherently different to
> the paging model. Receiving an INVITE should indicate that there
> exists a desire to establish a conversation. Likewise, accepting
> the INVITE should indicate that the party is willing to commit to
> the conversation, however brief it may end up being. But if the
> reason for establishing the session was actually to circumvent
> some transport inefficiency, this user experience factor is lost.

If we assume that client software directly exposes the difference between
page and session model as part of the user experience, I agree with you.
(Yahoo, for example, has an IM and conference model that are clearly
different user experiences.) But it is entirely possible to present a page
model user experience while still using a session model underneath. (I am
withholding judgement as to whether this is a good idea.)  Indeed, many
people appear to consider session vs. page mode selection as based on
content size and congestion issues rather than on user experience.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 16 May 2002 15:17:10 -0400

> via TCP. A general fix might lie there.

Right. We did that to handle backwards compatibility with UAs that are
pre-bis and don't support TCP.

I must admit that I also dislike the artificial limit. But, I've been
thinking about this more, and I think a different perspective on it
helps. Generally, page mode allows arbitrarily large content to be sent.
However, after a certain size is exceeded, the protocol moves to a model
of indirect content instead of directly sending it. I would argue that
the reason for this is not so much congestion control, but consent. If
you are sending an IM to a user on a wireless phone, you really don't
want to send them that 300meg movie unless they really want it. Content
indirection allows the recipient the ability to decide whether they want
the content now or later. This makes a lot of sense for content of
varied types and of larger sized content.

So, overall, an IM system that provides page mode can support messages
of any size, it just requires content indirection to support the larger
stuff.

So, all of that means we need this little content indirection thing
pretty badly, after all. My sense from the interim meeting was that the
requirements work was actually in pretty good shape, and we were ready
to get moving on the implementation, which is also pretty
straightforward. It really belongs in sip not simple, though. I hope our
ADs would be gracious about getting a work item into sip whose purpose
is to greatly enhance the story on consent and congestion control.... ;)

-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

---

From: Sean Olson <[email-masked]>
Date: Thu, 16 May 2002 15:35:46 -0700 (PDT)

The consent piece is an interesting adjunct to the
content indirection requirements. I already allude
to the fact that you need to be able to negotiate
support / demand for such a mechanism. 

Do we need to express explicit policy about when
content indirection should be used?

/sean

--- Jonathan Rosenberg <[email-masked]>
wrote:
> > even a bis proxy can choose to switch to UDP if it
> cannot reach the next
> > hop
> Sip mailing list 
> https://www1.ietf.org/mailman/listinfo/sip

__________________________________________________
Do You Yahoo!?
LAUNCH - Your Yahoo! Music Experience
http://launch.yahoo.com

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 17 May 2002 11:31:00 -0400

> content indirection should be used?

What I was saying is that the page mode spec DEFINES that policy
explicitly - anything over 1300 bytes means indirection.

-Jonathan R.

---

From: Michael Thomas <[email-masked]>
Date: Fri, 17 May 2002 08:52:23 -0700 (PDT)

> explicitly - anything over 1300 bytes means indirection.

Jonathan,

While I like the spirit of your proposal, I wonder
if it's going to run into operational problems.
Client's don't typically run web servers
(especially on some well known OSen). Also: some
cable MSO's filter port 80 to kill home web
servers. That means that they'd have to find and
upload that data to a willing web server. For
long-lived data that's not unreasonable, but for
short term/transient data that seems like a pretty
big burden.

When we discussed this ages ago it was in the
context of inlining jpeg mug shots and the like.
However if the context is IM, I'm not so sure
again. 

	   Mike

---

From: "Dean Willis" <[email-masked]>
Date: Fri, 17 May 2002 13:59:40 -0500

One must ask -- at what point should one transition from IM to email?

Mike rote:
>  > What I was saying is that the page mode spec DEFINES that 
> policy  > explicitly - anything over 1300 bytes means indirection.
> 
> 
> Jonathan,
> 
. . .

---

From: Michael Thomas <[email-masked]>
Date: Fri, 17 May 2002 12:14:16 -0700 (PDT)

> One must ask -- at what point should one transition from IM to

   Immediately?

	Mike, buddyless

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 17 May 2002 15:51:17 -0400

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.

---

From: "Ben Campbell" <[email-masked]>
Date: Fri, 17 May 2002 16:16:40 -0500

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?

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 17 May 2002 17:28:26 -0400

Plus, even if we do (1), this does not preclude (3) and maybe even (2) 
in the future, should there be a demonstrated need.

---

From: "Eric Burger" <[email-masked]>
Date: Fri, 17 May 2002 17:41:21 -0400

If we can wait, I would actually rather do #3.

#2 is a non-starter; there are too many proxies that would blithely pass
along the content.

#4 is a non-starter; this is asking to break the Internet.  We all know that
people will use IM instead of e-mail to send that 4MB presentation and that
3GB movie.

#1, which works, is a hack.  It also will break some QoS schemes.  E.g., SIP
signaling gets higher priority than e-mail.

#3 is, in a sense the correct answer (short of the truly correct answer on
not sending content in a session initiation protocol, but that's another
flame...).  If the question of the proxy is, "can you safely transmit
this?", then let us ask that question!

To show the silliness of sending content in a session protocol, another
solution that has not been mentioned yet would be to put congestion control
into SIP #-)))   [eyes shut closed!]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Ben
Campbell
Sent: Friday, May 17, 2002 5:17 PM
To: Henning Schulzrinne; Michael Thomas; Dean Willis; 'Jonathan
Rosenberg'; 'Sean Olson'; [email-masked]
Cc: [email-masked]
Subject: RE: MESSAGE size limitations (Was: RE: [Sip] Message draft
changes)

Thoughts?

---

From: "Ben Campbell" <[email-masked]>
Date: Fri, 17 May 2002 16:51:58 -0500

Agreed, although the current wording might preclude that. Maybe it would be
worth a slight mod that says if you _know_ all hops are congestion
controlled, you can exceed the limit. Then a future solution for 2 and 3
would not be precluded.

> Sent: Friday, May 17, 2002 4:28 PM
> To: Ben Campbell
> Cc: Michael Thomas; Dean Willis; 'Jonathan Rosenberg'; 'Sean Olson';

---

From: [email-masked]
Date: Sat, 18 May 2002 07:54:20 +0300

> for large content messages. I'm not sure how hard that charge would be to

i'm not quite sure what the above means, but i'm in favor of using
hop-by-hop tcp for large messages.  if the next sip hop doesn't speak
tcp, then the message would simply be rejected until the proxy or the us
of the next hop is upgraded.  this is not different from other sip
messages, such as invite, which too can easily be bigger than the mtu of
a link.

-- juha

---

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

> short term/transient data that seems like a pretty

Well, in the wireless world, there is an argument to be made
that almost all large data won't be stored on the phone in any case,
but rather available on a server. Clearly there are exceptions (those
new phones with built in cameras, i.e., the Danger device), and
clearly this isn't true for PCs on the wired Internet.

However, if we had a procedure that allowed an automata on the phone to
upload content
to a server, specify a lifetime, and set permissions on who can fetch
the
content, I see no drawbacks to the approach of uploading it to such a
server.
These kinds of servers are already features of existing wired IM
solutions,
which use them mostly for file transfer right now. 

-Jonathan R.