Subject: Re: [Simple] Messages: Signaling, Data, or Theft (Wassomethingto do wit message threading)

From: Heil Franca Marcelo ICM N PG U ID A 2 <[email-masked]>
Date: Fri, 15 Mar 2002 11:34:51 +0100

Comments below:

> 
> 
> 
> 
> Ben Campbell wrote:
> > 
> > > Also a question: what if there is a single TCP connection between
> > > UA and proxy. Proxy starts to transmit a large MESSAGE toward UA.
> > > In the meanwhile an INVITE for a voice call arrives at the proxy
> > > to be delivered to the same UA. Is it possible to interleave it
> > > between the TCP segments carrying MESSAGE, or does MESSAGE block
> > > the transport?
> > >
> > 
> > That could be a problem in some scenarios. I think the real 
> answer, though,
> > is to limit the MESSAGE requests to some reasonable size. 
> We have had talk
> > about standardizing methods to send large data by 
> reference--I think any
> > real application that sends messages containing much bigger 
> than an average
> > text IM will eventually need to go that route.
> 
> This is probably reasonable for page mode IM, but less 
> reasonable for session mode. Once you have gone to the 
> trouble to establish a session, it should be ok to send bigger
> messages over it.
> 
> 	Paul

I support limiting the size of MESSAGE requests for page mode IM.
Otherwise, network components (e. g. proxies) which are not really concerned
with IM contents would be unnecessarily burdened. For example, intermediate
proxies having to process, route and forward large MESSAGEs (with sizes in
the order of megabytes) arriving frequently would quickly run out of memory
resources. 
Session mode IMs should be expected to be transferred end-to-end using an
appropriate transport protocol, so that intermediate proxies should not be
in the path and therefore not  directly involved in the IM transfer. Session
mode seems, therefore, much more appropriate for tranferring large IMs than
page mode.
Marcelo
_______________________________________________
simple mailing list
[email-masked]
http://mailman.dynamicsoft.com/mailman/listinfo/simple

---

From: "Dean Willis" <[email-masked]>
Date: Fri, 15 Mar 2002 09:52:36 -0600

Marcelo wrote:
> I support limiting the size of MESSAGE requests for page mode 
> IM. Otherwise, network components (e. g. proxies) which are 
> not really concerned with IM contents would be unnecessarily 
> burdened. For example, intermediate proxies having to 
> process, route and forward large MESSAGEs (with sizes in the 
> order of megabytes) arriving frequently would quickly run out 
> of memory resources. 

The genral approach that I believe has been agreed on is that MESSAGES
should not exceed a size slightly smaller than a reasonable path MTU
because there MAY bea a UDP link somewhere in between, and fragmenting
over a UDP link increases the probability of a fragment loss (not to
mention posing interesting issues for congestion management). Beyond
this point, reducing them in size doesn't significantly affect the proxy
performance, because the proxy load is driven by the forwarding logic
and signaling state machines and not the I/O of the message body.

> Session mode IMs should be expected to be transferred 
> end-to-end using an appropriate transport protocol, so that 
> intermediate proxies should not be in the path and therefore 
> not  directly involved in the IM transfer. Session mode 
> seems, therefore, much more appropriate for tranferring large 
> IMs than page mode. Marcelo 

Page mode IMs don't necessarily transit the intermediate proxies. If the
contact address of the destination is known, and the network topology
has not been deliberately designed to prevent it, one can send the
MESSAGE directly to the far end. Let's not let the fact that some people
have deliberately obfuscated their networks with "required" proxies make
us forget about the intended end-to-end nature of the Internet.

The general idea of a proxy is as a "location service" aid -- if you
don't know how to get directly to somoeone (or can't, due to topology),
you can ask a proxy to help. In fact, one could use pager-mode MESSAGES
over a persistent end-to-end TCP or TCP/TLS session, and get all the
benefits of congestion control, retransmission, in-order delivery, and
reassembly.

This is most interesting because the intended nature of the "sips:" URI
mechanism is that every link be TLS (which implies TCP or SCTP). So the
use of sips: on MESSAGE requests most all of the UDP-related issues,
esepcially when used directly with a sips: contact.

Combine this with the use of redirection (302) messages instead of
"proxying", and one can get e2e sessions (which transport pager-mode
MESSAGES as well as other SIP) in a very nice end-to-end fashion. And
there's probably something that could be done to optimize the flow by
allowing intermediate proxies that absolutely MUST stay on the path to
"cache" 302 responses and recurse on them to provide automatic MESSAGE
path optimization.

--
Dean

--
Dean

---

From: "Ben Campbell" <[email-masked]>
Date: Fri, 15 Mar 2002 10:28:56 -0600

> "cache" 302 responses and recurse on them to provide automatic MESSAGE

Keep in mind though, that MESSAGE does not initiate a dialog. The affect
here is that, in the absense of something like a "Moved Permantly"
redirection, Each subsequent MESSAGE request to a given address of record
will follow a similar path--that is, there is no real way _not_ to record
route.

That of course does not prevent the _initial_ route to end up e2e, with the
use of redirect servers as you mention. But each subsequent message must
also get redirected.

---

From: "Dean Willis" <[email-masked]>
Date: Fri, 15 Mar 2002 11:17:44 -0600

Ben points out:
> Keep in mind though, that MESSAGE does not initiate a dialog. 
> The affect here is that, in the absense of something like a 
> "Moved Permantly" redirection, Each subsequent MESSAGE 
> request to a given address of record will follow a similar 
> path--that is, there is no real way _not_ to record route.
> 
> That of course does not prevent the _initial_ route to end up 
> e2e, with the use of redirect servers as you mention. But 
> each subsequent message must also get redirected.

That's what I mean by "caching" redirections.

Say we have:

UA1--->P1--->LS
        |
        |
        UA2

Where the normal flow is something like:

UA1->INVITE target@lS->P1
P1->INVITE target@ls->LS
LS->302 target@UA2 -> P1
P1 -> INVITE target@ls -> UA2

Or

UA1->MESSAGE target@lS->P1
P1->MESSAGE target@ls->LS
LS->302 target@UA2 -> P1
P1 -> MESSAGE target@ls -> UA2

Now, the normal model is that for each subsequent INVITE or MESSAGE to
go through the same process.

But what if P1 "remembers" that it has been recently redirected for this
request URI, and just keeps on using it, like:

UA1->INVITE target@lS->P1
P1 -> INVITE target@ls -> UA2

Or

UA1->MESSAGE target@lS->P1
P1 -> MESSAGE target@ls -> UA2
 
Certainly, this raises some questions:

1) How long to "remember" -- it's not permanent, but it's longer than 1
message . . .

2) What happens if we keep sending to the redirected contact "too long"
and the user has already moved somewhere else?

3) the caching operation is clearly proxy stateful

4) we could implement this sort of 302 caching in a UA too

A couple of possibilities spring to mind.

1) We could add something like a duration indicator to the 302 response,
much like the TTL on DNS lookups. Or we could contrive to do something
at the DNS level, although this really doesn't give us the message-type
specific behavior potentially provided by the LS in this example. Or we
could rely on a "bounce" from question 2 to let us know that the
situation has changed and we need to reconsider the route.

2) If the contact that P1 is redirecting too stops responding (timeout
or ICMP response) then P1 knows to flush the cache. This begs the
question of what happens if the redirection policy at LS changes --
using this model, we'd continue talking to the original redirection
contact until some other mechanism causes a transition, which might be
acceptable.

3) Yes, all 302-recursions are at least transaction satteful at the
proxy. 

4) Actually, any point that does a 302-recursion could implement this
sort of approach.

--
Dean

---

From: "Ben Campbell" <[email-masked]>
Date: Fri, 15 Mar 2002 12:58:14 -0600

> situation has changed and we need to reconsider the route.

Actually, the current SIP spec officially supports the use of the Expires
header in 302 responses for this purpose.

---

From: "Dean Willis" <[email-masked]>
Date: Fri, 15 Mar 2002 16:33:03 -0600

> > 1) We could add something like a duration indicator to the 302 
> > response, much like the TTL on DNS lookups. Or we could 
> contrive to do 
> > something at the DNS level, although this really doesn't 
> give us the 
> > message-type specific behavior potentially provided by the 
> LS in this 
> > example. Or we could rely on a "bounce" from question 2 to 
> let us know 
> > that the situation has changed and we need to reconsider the route.
> 
> Actually, the current SIP spec officially supports the use of 
> the Expires header in 302 responses for this purpose.

Ahah. 

So: By combining this with proxy-recursion on 302 responses, we have a
way to optimally target MESSAGES (and other traffic) to a particular end
point in such a way that proxies that MUS Tbe on the path are retained,
and those that don't have to be aren't.

All it takes are two rules:

1) A "proxy" node that does not want to stay in the loop 302 redirects
to the next hop, rather than proxying

2) A "proxy" node which proxies recurses on 301/302 responses and MAY
record-route if it wants to be in-the loop for all messages in a
resulting dialog

Actually, I think this solves a whole lot of things . . . 

--
Dean