Subject: RE: [Sip] Myth Busters: Episode 1, Is STUN requestprocessingfaste r than a SIP PING request processing?

From: "Francois Audet" <[email-masked]>
Date: Fri, 17 Mar 2006 20:08:07 -0600

Actually, the evidence presented so far pointed to the opposite,
i.e., that a new method was actually slightly less resource intensive
than STUN.

> -----Original Message-----
> From: Elwell, John [mailto:[email-masked]] 
> Sent: Friday, March 17, 2006 05:57
> To: Christian Jansson; Srivastava, Samir [SC100:8826:EXCH]; 
> Cullen Jennings; Christer Holmberg (JO/LMF); Hisham 
> Khartabil; [email-masked]
> Subject: RE: [Sip] Myth Busters: Episode 1,Is STUN 
> requestprocessingfaste r than a SIP PING request processing?
> 
> 
> Christian,
> 
> I agree, and I would also eliminate option 2, because it 
> seems clear from evidence presented to date that any SIP 
> method that is conformant with normal SIP rules will have  a 
> significant impact on scalability.
> 
> John 
> 
> > -----Original Message-----
> > From: Christian Jansson [mailto:[email-masked]]
> > Sent: 17 March 2006 09:49
> > To: Samir Srivastava; Cullen Jennings; Christer Holmberg 
> > (JO/LMF); Hisham Khartabil; [email-masked]
> > Subject: RE: [Sip] Myth Busters: Episode 1, Is STUN 
> > requestprocessingfaster than a SIP PING request processing?
> > 
> > > Samir wrote:
> > >STUN with magic binary cookie is hack too.That looks to me 
> going back 
> > >to binary protocols and defeating the purpose of text based SIP 
> > >protocol.
> > 
> > So in principal you rather have something that is human 
> readable than 
> > something that works better in reality?
> > 
> > 
> > >Another point  "Every application protocol
> > >should take of its own mess using its own primitives" .
> > 
> > You mean we should for example also use SIP instead of DNS, 
> DHCP, and 
> > RTP? In general I think it is better to use a tool that is designed 
> > for the problem.
> > 
> > >Within SIP too all headers doesn't
> > >apply to all methods, we are doing this to achive the performance.
> > 
> > SIP parsing and performance are not optimized, that is a 
> fact. SIP and 
> > human readability on the other hand... but who cares.
> > 
> > >So PING is lesser evil than STUN.
> > 
> > If PING was SIP I would have no problem with it, but as it 
> is defined 
> > right now PING is not SIP even though the draft wants it to 
> be. And I 
> > do not think we should standardize things that are plain wrong
> > just because
> > it for the moment does not seem to introduce any enormous problems.
> > 
> > I think we have 3 real options:
> > 1. Double CRLF
> > 2. A new real SIP method
> > 3. STUN
> > 
> > Bad ideas:
> > 4. Using OPTIONS is a bad idea as it has another purpose, and
> > adding new
> > method would cost us nothing and it would be very clear 
> what was going
> > on.
> > 5. Using PING as it is being discussed right now is not an option as
> > long as it is not SIP as it claims to be. I do not want to 
> > see any more
> > discussions of non-SIP things that just looks like SIP anymore.
> > 
> > / Christian Jansson
> > 
> > 
> > _______________________________________________
> > Sip mailing list  https://www1.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
> > 
> 
> _______________________________________________
> Sip mailing list  https://www1.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
> 
> 

_______________________________________________
Sip mailing list  https://www1.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: Adam Roach <[email-masked]>
Date: Fri, 17 Mar 2006 21:27:51 -0600

John Elwell wrote:

>...it seems clear from evidence presented to date that any SIP 

>i.e., that a new method was actually slightly less resource intensive

You are either misinterpreting Hisham's experiment or John's comment.

John is referring to a new method that "is conformant with normal SIP 
rules."

Hisham's experiment was using a TCP connection established for SIP to 
send a pile of bits that, upon casual examination, looks a whole lot 
like a SIP message but which most emphatically IS NOT.

Jonathan and others have posted concrete examples in which doing what 
Hisham did makes the network fail in new and spectacular ways.

/a

---

From: "Frank W. Miller" <[email-masked]>
Date: Sat, 18 Mar 2006 00:30:17 -0500

> Hisham did makes the network fail in new and spectacular ways.

IIRC, Jonathan's concerns centered on my proposal to not use the
standard retransmissions associated with a NIT.  The most recent version
of the draft, -02, removes this based on the potential problems he
identified.  Sending a PING in this version initiates and maintains
standard NITs along the signaling path.  This makes the request very
definitely a normal SIP message that follows all the normal rules.

That said, the -02 version of the draft also includes a paragraph about
the optimization discussed here for a UAS 200 OK response generation.
The optimization is not required, but if the endpoint UAS uses it to
turn a 200 around quickly, it can certainly make that transaction very
quick.  I know in my own UA implementation, I use a similar procedure
for turning OPTIONS requests around and have never had any problems with
it and its been tested against a number of other implementations.

FM

---

From: Aki Niemi <[email-masked]>
Date: Sun, 19 Mar 2006 17:49:43 +0200

I agree. Pekka Pessi explained the issue already much better than I ever
could:

http://www1.ietf.org/mail-archive/web/sip/current/msg12841.html

In summary: processing STUN and, say, OPTIONS consumes roughly the same
amount of packets on-the-wire, system calls and both parsers (alone) fit
in modern processor caches. So the bottleneck is somewhere else than in
CPU, like in memory bus or network I/O. (This might actually be worse
for a combined SIP+STUN parser, but I don't have concrete data on that
unfortunately.)

To which Jonathan replied that bandwidth is also an issue to consider,
and would favor a protocol that was smaller on the wire:

http://www1.ietf.org/mail-archive/web/sip/current/msg12842.html

However, the data Jonathan presented assumes a proxy that only sees VoIP
traffic. I don't think you can restrict "useful traffic" to VoIP only.
If you take a proxy that not only sees INVITE/200/ACK, but presence and
IM as well, the numbers change. I recently saw numbers from a real
deployment that accounted almost 90% of the messages seen by proxies to
be presence related; VoIP only accounted for approximately 6% of
messages. The graphs didn't show bandwidth figures, but I'd expect them
to be ever worse.

Cheers,
Aki