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

From: [email-masked]
Date: Thu, 14 Mar 2002 21:43:28 +0200

Hi,

Scheduling within proxies is one thing. Also important is how the IP packets carrying SIP are handled over low-capacity links. For example in wireless access, session setup maybe treated differently from regular traffic in order to meet the call setup times. On the other hand large MESSAGEs etc. could be treated as best-effort. DiffServ codepoints might be used to do the thing, but this requires the last hop proxy to set them based on some logic. Probably this is nothing to do with SIP protocol, though. 

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?

Markus

> -----Original Message-----
> From: ext Henning Schulzrinne [mailto:[email-masked]]
> Sent: 14 March, 2002 17:57
> To: Michael Hammer
> Cc: [email-masked]
> Subject: Re: [Simple] Messages: Signaling, Data, or Theft
> (Wassomethingto do wit message threading)
> 
> 
> There are a number of techniques, e.g., I vaguely remember work
> published recently related to web servers from folks at IBM, 
> that allow
> prioritization for different classes of requests. Thus, I 
> just don't see
> this as a protocol issue.
> 
> Michael Hammer wrote:
> > 
> > Henning,
> > 
> > Dave is right once you get beyond accounting for the 
> traffic, billing is
> > more an arbitrary business issue.
> > 
> > Back to what I perceive as the main technical question though:  Will
> > session setup (signaling) packets get priority (within 
> proxy processing)
> > over IM packets such that session setup time is not 
> impacted?  Or will
> > users re-initiate after a second or two exacerbating the 
> traffic load?  Or
> > as some have suggested, does SIP traffic get segregated and 
> travel over
> > different proxies?  Does the protocol element exist to 
> discriminate so?
> > 
> > Mike
> _______________________________________________
> simple mailing list
> [email-masked]
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
> 
_______________________________________________
simple mailing list
[email-masked]
http://mailman.dynamicsoft.com/mailman/listinfo/simple

---

From: "Dean Willis" <[email-masked]>
Date: Thu, 14 Mar 2002 15:44:19 -0600

> 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 is transport dependent -- does your transport protocol provide for
subpacketization and interleaving?

There was a big push to provide this with PPP back when people thought
they were going to be doing voice over IP over dialup, and we found that
every large TCP packet blew the RTP jitter buffer due to serialization
delay. Somebody who's brain works better than mine can probably produce
a reference for the PPP variation, which I think was never widely
deployed.

One could hope that the wireless transport people provide something like
that. I have the sneaking suspicion they didn't, at least yet.

--
Dean

---

From: "Ben Campbell" <[email-masked]>
Date: Thu, 14 Mar 2002 16:06:59 -0600

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

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 14 Mar 2002 18:21:03 -0500

> 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

---

From: Dean Willis <[email-masked]>
Date: Fri, 15 Mar 2002 13:15:41 -0600

Actually, if you do the math, you find that something like 64 bytes is 
the largest message size whose serialization delay doesn't break RTP at 
9600 bps. That makes it a sub-IP interrleaving problem.

--
Dean

On Thursday 14 March 2002 04:06 pm, Ben Campbell wrote:
> 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.
>