Subject: RE: [Simple] simple-message-sessions

From: Adam Roach <[email-masked]>
Date: Mon, 4 Aug 2003 15:44:00 -0500

Cullen Jennings writes:

> I don't think this document has had the discussion
> it deserves. For example: the question of why this
> is better than just running MESSAGE over SIP on TCP
> has never been answered.

1. It's smaller than SIP.

  I just had a discussion with handset manufacturer in which
  they expressed concern about the large number of mandatory
  headers (on the order of 500 - 1000 bytes) just to send a
  MESSAGE. I assured them that message sessions, with header
  blocks much closer to 50 bytes, would alleviate many of
  their concerns.

2. It doesn't traverse the proxy network

  Just using MESSAGE over TCP requires proxies to stay in
  the path of the messages. While this can be avoided in
  theory, such avoidance is exacerbated by the fact that
  MESSAGE messages don't create sessions.

3. It doesn't allow advanced call control

  On a related note, the fact that MESSAGEs exist outside
  of dialogs make them nearly impossible to manage. You
  can't perform REFER; you don't get to leverage the XCON
  (and any future conferencing work); all other call control
  stuff doesn't work. With message sessions, IMs are just
  another media stream.

There are probably other major advantages that I'm missing at
the moment, but those are the three that loom largest in
my mind.

/a

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 04 Aug 2003 15:17:43 -0700

Sorry - I was not clear on something. I was not proposing using page mode. I
was comparing to using signaling to set up a session of message that looked
a lot like SIP. 

Adam and I talked about this one the phone. Adam pointed out that

1) It is smaller even with sigcomp because the via tags don't compress.

2) Congestion issues are pretty much the same as they are for things like
Yahoo or AOL today.

Cullen

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 04 Aug 2003 15:17:43 -0700

Cullen

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 05 Aug 2003 10:45:07 -0400

inline.

> 2) Congestion issues are pretty much the same as they are for things like

Well, specifically, it is my understanding that N parallel TCP 
connections (as opposed to 1) still provides congestion control. There 
are other side effects, though. In particular, I believe (and someone 
who knows more than me can confirm) that a single connection would 
provide overall better throughput, since the window will generally 
stay open because there is usually traffic. A larger number of 
connections, each of which gets opened for a new session and sees 
sporadic traffic, will tend to be in slow start more often and thus 
reduce the overall throughput.

However, I'll also note that, in our ideal case, there would be no 
intermediaries, and you'd end up with direct tcp connections anyway. 
That said, I am interested in spec'ing out SCTP for inter-relay usage, 
as it would address the throughput issue above, and also reduce the 
number of connections that a relay needs to maintain.

In my mind, message sessions is really two protocols that can almost 
be separated. One of them is the protocol used to obtain bindings and 
visit remote relays. This protocol is very similar to TURN. The other 
protocol is a message shim layer that allows us to carry mime content 
over a tcp connection, established directly or over relays. Cullen, it 
sounds like your beef is with the shim layer that carries MIME 
content. Is that right? Is your issue the requirement for another 
parser? The shim seems simple enough, its not clear to me that this is 
a real issue.

If your beef is with the protocol to establish the relay connections, 
where the alternative is SIP (REGISTER == BIND), there are real issues 
there. Using SIP was the essence of the IMTP proposal way back. The 
problems with that were:

1. you can't just use SIP; you need to remove a bunch of features 
which really don't work for this application. UDP fallback, forking, 
redirection.

2. A whole bunch of SIP features are simply unneeded and end up 
bloating the messages (record-routing, via processing, tags, etc.).

3. Specing a protocol that is a proper subset of SIP, removing the 
items from 1 and 2 above, is frought with peril. I've been down that 
road several times now in other protocols. Inevitably, its horribly 
unclear about exactly what the subset is. Worse, the main protocol 
evolves, through extensions and revisions - how do those get tracked 
in the subsetted protocol?

In the end, the easiest thing is to define a standalone protocol that 
represents just what you want. And thats what we've done.

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 05 Aug 2003 10:45:07 -0400

inline.

Thanks,
Jonathan R.

---

From: Dean Willis <[email-masked]>
Date: 08 Aug 2003 15:28:34 -0500

> reduce the overall throughput.

I tend to think that's exactly backwads. N parallel connections would
have much BETTER throughput (at least after slow-start ramps up), but
are more competitive for network resources with other TCP connections
and therefore more likely to adversely affect congestion. Also, there is
no head-of-line blocking between message sessions if each message
session is on a seperate socket.

A lot does depend on the persistence of the message session, the TCP
slow-start options selected, wehether the Nagle algorithm is suppressed,
and so on. It seems to me this is something that could benefit from the
new fast-adapting TCP stuff that Sally Floyd has been reporting on in
TSVWG.

> number of connections that a relay needs to maintain.

SCTP has huge advantages for inter-relay use.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: 08 Aug 2003 15:28:34 -0500

--
Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 08 Aug 2003 17:52:41 -0400

> SCTP has huge advantages for inter-relay use.

I think we concluded that SCTP for inter-relay use still has problems 
with blocking interactions between sessions because it has no way to 
apply back pressure on a per-stream basis.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 08 Aug 2003 17:52:41 -0400

Paul

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 10 Aug 2003 00:21:30 -0400

> apply back pressure on a per-stream basis.

Sure, but this isn't a symptom of SCTP. We have the same problem with 
TCP, no?

The primary benefit of SCTP would be a reduction in the number of 
connections between relays.

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 10 Aug 2003 00:21:30 -0400

-Jonathan R.