Subject: RE: [Sip] I-D ACTION:draft-kiss-sip-s100rel-00.txt

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 24 Jul 2001 18:08:11 -0400

> -----Original Message-----
> From: Christer Holmberg [mailto:[email-masked]]
> Sent: Monday, July 23, 2001 7:14 AM
> To: [email-masked]
> Subject: Re: [Sip] I-D ACTION:draft-kiss-sip-s100rel-00.txt
> 
> 
> 
> Hi,
> 
> I'm the first to admit (I've mentioned it before) that the PRACK
> mechanism is very "heavy", and what you propose has been discussed
> before (I think I was even one of those who proposed it back then...),
> but the argument against it was that it is against the SIP semantics,
> since ACK is the ONLY method which is sent without a response - and I
> think that makes very much sense.
> 
> So, while we can (and we SHALL) come up with new cool 
> features for SIP,
> we should avoid touching the protocol core. In this case we would have
> to change the semantics of a SIP transaction, since the bis specifies
> how INVITEs are handled, how ACKs are handled, and how ALL 
> OTHER methods
> (standard- or extension methods) should be handled - ie we 
> would have to
> change the bis too. Do we want to do that?

No, we don't.

I think this approach is a bad idea. It has been discussed and discarded at
least twice so far on the lists. Maybe third time is the charm.

WHy is it really bad? Well, draft-ietf-sip-guidelines clearly describes why.
THe extension mandates Proxy-Require *and* Require. According to the
guidelines draft:

The Proxy-Require header SHOULD be avoided at all costs. The
          failure likelihood in an individual proxy stays constant, but
          the path failure grows exponentially with the number of hops.

This means that you are going to have an exponentially increasing
probability of needing to fallback to the normal PRACK behavior, and the
resulting cost is that these cell phones, whom you are trying to serve, now
need to implement two already-complex specifications. 

Now, if I ignore the fact that this extension is effectively not backwards
compatible with SIP, there is another problem, which is that it really
doesn't achieve any useful results.

The supposed goal, as outlined in the introduction, is:

  The motivation for defining an alternative approach to [6] is that
   certain networks, e.g. cellular networks, have limited bandwidth
   for signalling purposes. Thus every extra message in the session 
   initiation increases the duration of the session setup, which might 
   cause that the session setup delay crosses the acceptable limit.

This makes no sense to me. I'm assuming that the reliable provisional
responses are being used to acknowledge the 1xx used for manyfolks. Once the
provisional response is received, resource resveration can happen in
PARALLEL with the transmission of PRACK/200, and the final response to the
INVITE can also happen in parallel to that. So, call setup time is not
affected.

Perhaps you are concerned about overhead on the wireless link. In terms of
byte savings, using something like the ROGER protocol or my UDP compression
proposal,
http://www.jdrosen.net/papers/draft-rosenberg-rohc-sip-udpcomp-00.txt, you
get far, far, far better compression gains than the improvements afforded
from eliminating this message.

So, the SPRACK proposal:

1. necessitates Proxy-Require, which is an effective break in compatibility
with the SIP protocol,
2. doesn't really help call setup times for the manyfolks flows
3. provides tiny compression compared with other alternatives.

So, I do not understand why this is a good path to follow.

-Jonathan R.

---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
Sip mailing list  http://www.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: [email-masked]
Date: Fri, 27 Jul 2001 16:08:14 +0300

Hi Jonathan,

>           the path failure grows exponentially with the 

This is true if you assume that the support for a feature is a random
variable. However, it could also be possible to deploy a new feature in
proxies by implementing it in islands of proxies such as ones serving
wireless hosts.  
 
> need to implement two already-complex specifications. 

This is a valid point unless the wireless-serving proxies would in most
cases support SPRACK. However, what I have heard, SIP implementation in
phone is not as big issue as delays are. 

> from eliminating this message.

Yes, call setup delays and wireless link overhead would be the main
motivation for trying to reduce the number of messages/bytes needed. It's
true that QoS setup & radio bearer establishment can start right at the same
time as PRACK is being sent and 200 OK for it is being waited for.

However, especially if compression is not used, we have calculated that
PRACK-200 RTT takes actually longer than QoS setup in some of the wireless
systems (read GERAN) that we are dealing with. So, that is the constraint. I
agree it may not be a big difference, and if compression is being
standardized, as I really hope, your argumentation is correct.

There is still another issue. What if 200 OK for PRACK or any other SIP
message is lost? That causes a retransmission, and the call setup delay
becomes larger. Following the reasoning you had above about the proxies, the
likelihood of loss grows exponentially with the number of messages. 

> 1. necessitates Proxy-Require, which is an effective break in
compatibility

The extension COULD be used with Proxy-Require,
however in the I-D we propose the usage of _Proxy-Supported_,
(as described in draft-hoeneisen-sip-proxy-supported-00.txt)
which means, that the call can be set-up with the first
INIVITE and depending, whether all record routing proxy
servers support the s100rel, either the s100rel or the
100rel mechanisms are applied, i.e. no 420 Bad Extension
for s100rel is sent by any proxy server.
There will be no path failures with this proposal.

> 2. doesn't really help call setup times for the manyfolks flows

In some cases it does, as explained above. I agree that compression is more
important, though. 

> 3. provides tiny compression compared with other alternatives.

OK.

> So, I do not understand why this is a good path to follow.

IF it was possible to redo SIP, would Provisional Responses/PRACK be done
differently? I guess so. Our proposal is one way, and it provides backwards
compatibility with a fallback system. I don't know if there ever will be
SIPv3...

> http://www.dynamicsoft.com

Markus

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 30 Jul 2001 13:00:39 -0400

> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, July 27, 2001 9:08 AM
> To: [email-masked]; [email-masked];
> [email-masked]
> Subject: RE: [Sip] I-D ACTION:draft-kiss-sip-s100rel-00.txt
> 

SIP does not assume a closed universe. I would like for those wireless
handsets to be able to call wireline SIP phones supported by existing SIP
proxies. Your proposal will require all record-routing proxies to support
this extension, including ones outside of the "wireless islands".

> standardized, as I really hope, your argumentation is correct.

There are something like 4 drafts on the subject of sip compression within
the rohc group. I plan on attending the meeting to argue that this work be
taken up as a standards track item somewhere, probably rohc. Without that,
there will be a MILLION proposals for a vagary of "improvements to sip for
wireless performance", which will all ultimately kill sip interoperability
and get performance improvements only by by slowly and painfully hacking up
the protocol in ways much like you propose. A middle-layer compression gives
tremendous benefits in terms of compression and wireless performance without
killing the protocol. The cost is a moderate increase in complexity, and I
feel that is well justified.

> likelihood of loss grows exponentially with the number of messages. 

This is no different in what you are proposing. You still need
retransmissions for reliability. In your case, what if the 1xx is lost? Or
the PRACK is lost? Same difference.

> There will be no path failures with this proposal.

Well, you are adding even more complexity and mess with this
Proxy-Supported, just to support this one thing which buys you something
like 5% improvement in bandwidth usage and questionable improvements in
latency. This is what I mean about lots of hacks to the protocol, cutting it
to pieces until it dies....

> compatibility with a fallback system. I don't know if there 

If I could do SIP over from scratch, I would change many, many things, not
the least of which was reliability of provisional responses. But, we have no
such luxury.

-Jonathan R.

---