Subject: RE: [SIP] Last Call: Reliability of Provisional Responses in SIP to Proposed Standard

From: Subramania Sivaram <[email-masked]>
Date: Mon, 28 Aug 2000 17:51:21 +0530

This document looks good. However, being new to this mailing list, I have a
fundamental
question. Why was it chosen to support a call control protocol like SIP over
an unreliable
transport protocol like UDP. HTTP, on which SIP is based, works over a
reliable transport,
all call control protocols in the PSTN world, like SS7, Q.931 etc. work over
a reliable
transport. This draft <draft-ietf-sip-100rel-02.txt> and several parts of
SIP specification
seem to exist because of the need to make SIP work over an unreliable
transport protocol.

Regards,
Sivaram.

> -----Original Message-----
> From:	The IESG [SMTP:[email-masked]]
> Sent:	Saturday, August 26, 2000 2:56 AM
> Cc:	[email-masked]
> Subject:	[SIP] Last Call: Reliability of Provisional Responses in SIP
> to Proposed Standard
> 
> 
> The IESG has received a request from the Session Initiation Protocol
> Working Group to consider Reliability of Provisional Responses in SIP
> <draft-ietf-sip-100rel-02.txt> as a Proposed Standard.
> 
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send any comments to the
> [email-masked] or [email-masked] mailing lists by September 8, 2000.
> 
> Files can be obtained via
> http://www.ietf.org/internet-drafts/draft-ietf-sip-100rel-02.txt
> 
> 
> 
> 
> _______________________________________________
> SIP mailing list
> [email-masked]
> http://lists.bell-labs.com/mailman/listinfo/sip

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 28 Aug 2000 23:55:37 -0400

There were several reasons:

1. to improve the call setup times, which are an issue,
2. to enable highly scalable stateless proxies, which are used
extensively and are not possible with TCP,
3. to support low end phones for which tcp implementations can be an
issue 
4. to support intermittently connected devices for which tcp connections
are not ideal
5. to improve fault tolerance and provide the capability of hot
standby's and failovers; this is related to  (2), since this is possible
with stateless proxies.

In any case, the decision has long ago been made and widely implemented
(far more than tcp, in fact). 

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 28 Aug 2000 15:49:28 -0500

Subramania Sivaram wrote:
> 
> This document looks good. However, being new to this mailing list, I 
> have a fundamental question. Why was it chosen to support a call 
> control protocol like SIP over an unreliable transport protocol like 
> UDP. HTTP, on which SIP is based, works over a reliable transport,
> all call control protocols in the PSTN world, like SS7, Q.931 etc. 
> work over a reliable transport.
[...]

In a nutshell, timing and speed.  A signaling protocol like SIP needs 
finer access to timeouts and a fast transport.  TCP's three-way hand-
shake can take to the order of a few milliseconds on a LAN to hundreds
of milliseconds or a few seconds on a WAN.  

UDP provides SIP with a finer grain access to timing information as well 
as a fast transport.  Unfortunately, that comes with the disadvantage of
implementing re-transmission and ordering of packets.

Jonathan Rosenberg has a I-D on transporting SIP over SCTP, which is
being designed to be a faster (than TCP) and lighter (than TCP) 
transport protocol, but having some of the same reliability mechanisms
as TCP.

I am sure there are other reasons besides timing and speed; I can think
of these two off the top of my head.

Regards,

- vijay
-- 
Vijay K. Gurbani  [email-masked] [email-masked] [email-masked]
Internet Software Group/Intelligent Network and Instant Messaging
Lucent Technologies/Bell Labs Innovations, 263 Shuman Blvd, Rm 1A-413
Naperville, Illinois 60566  Voice: +1 630 224 0216 Fax: +1 630 713 0184

---

From: jimmy Zhang <[email-masked]>
Date: Tue, 29 Aug 2000 15:09:45 -0700

> transport protocol, but having some of the same reliability mechanisms

I thought SCTP is an application level protocol that is designed to be
transported
over TCP/IP. My question is why it would be faster than TCP/IP. Also what
is
the point of build an application level protocol on top of another?

--

Jimmy zhang ([email-masked])

Software Engineer

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 29 Aug 2000 17:36:13 -0500

jimmy Zhang wrote:
 
> transported over TCP/IP. 

It is -- for now.  I belive the intent is for it to be another transport
in addition to UDP and TCP and reside at the transport layer, or if it
does not reside at the transport layer, to directly use the services of
the IP layer (a la ICMP or OSPF).  BTW, IP had another "faster than TCP" 
but "more reliable than UDP" protocol called RDP (Reliable Datagram
Protocol) -- don't know why it never caught on (if you look in your 
/etc/protocols file, you may still find an entry for it).  W. Richard 
Stevens in one of his seminal books proposes T/TCP (Transaction Oriented 
TCP) to be in much the same vein.  Don't know why it never caught on, 
either.

> My question is why it would be faster than TCP/IP. 

Take a look at 
http://search.ietf.org/internet-drafts/draft-ietf-sigtran-sctp-13.txt
for many reasons.

> Also what is the point of build an application level protocol on top 
> of another?

Quick acceptance.  Until (and unless?) vendors modify their IP kernels 
to support another transport protocol, the easiest and most portable
way is to run it as an application level protocol.

I believe vendor support is coming soon.  Sun folks are talking about 
using SCTP for AAA.  Storage Area Network folks are talking about it
as well.

Regards,

- vijay

---

From: David Frascone <[email-masked]>
Date: Wed, 30 Aug 2000 06:58:41 -0500

> the point of build an application level protocol on top of another?

SCTP runs over IP, not TCP.  There is also a method to allow it to run over
UDP.

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 30 Aug 2000 09:11:22 -0400

> http://search.ietf.org/internet-drafts/draft-ietf-sigtran-sctp-13.txt

Actually, since RTO.initial is 3 seconds by default, the call setup
delay is not likely to be significantly lower than TCP.

---

From: David Israel <[email-masked]>
Date: Wed, 30 Aug 2000 08:44:00 -0400

> using SCTP for AAA.  Storage Area Network folks are talking about it

For SAN I am aware of two new protocols - DAFS (Direct Access File System)
and SoIP (Storage over IP),  which of these are considering SCTP?

Can you point us to a resource or person for Sun using SCTP for AAA?

Thank you,
David