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

From: "Samir Srivastava" <[email-masked]>
Date: Sun, 19 Mar 2006 15:43:25 -0600

Major portion of Overload and Congestion handling should be done in
*out-of-band* manner. Handling most of that on the same signaling  (
already overloaded/congested ) channel is architecturally incorrect,
though there can be some SIP signaling messages for it. That's where SIP
MIB comes into the picture. Overload / Congestion compliance will make
more vendors to implement SIP MIB, which is of low traction currently. 

SIP MIB captures the stats per method basis. It will be easy to extend
it for PING and find out the PING load (Which is a lot, refer Jonathan'
email link) in out-of-band manner. Finding STUN keep alive load using
MIB-II objects is not possible. MIB-II objects doesn't have per port
stats. There counters are transport protocol based. So it will not be
possible to catch CRLF stats from there.

Choices are :-

1) Extend MIB II to have per port basis stats. Which is not a available
route as SIP needs granular stats it better should have in its own MIB.

2) Treat STUN CRLF keep alive as SIP method for stats capturing (Bad
design).

3) Have PING method (which purist doesn't like).

IMHO 3) is best among the *available* choices for overload and
congestion problem to be addressed in future.

Thx
Samir

-----Original Message-----
From: Aki Niemi [mailto:[email-masked]] 
Sent: Sunday, March 19, 2006 7:50 AM
To: Audet, Francois [SC100:3055:EXCH]
Cc: Elwell, John; 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?

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

ext Francois Audet wrote:
> 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
> 

_______________________________________________
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: "Jeroen van Bemmel" <[email-masked]>
Date: Sun, 19 Mar 2006 23:05:43 +0100

Samir,

So in summary, you are saying "Since SIP MIB only supports statistics for 
SIP messages (and not per port), we should use SIP messages for keep-alive".

I would argue the other way around: If it is a requirement for SIP MIB to 
collect statistics for overload analysis, it may need to take into account 
more than only SIP messages, and may also need to provide per-port 
statistics

Regards,

Jeroen

----- Original Message ----- 
From: "Samir Srivastava" <[email-masked]>
To: "Aki Niemi" <[email-masked]>; "Francois Audet" <[email-masked]>
Cc: "Cullen Jennings" <[email-masked]>; <[email-masked]>; "Christer Holmberg 
(JO/LMF)" <[email-masked]>; "Elwell, John" 
<[email-masked]>
Sent: Sunday, March 19, 2006 10:43 PM
Subject: RE: [Sip] Myth Busters: Episode 1,Is STUN requestprocessingfaste r 
than a SIP PING request processing?

Choices are :-

Thx
Samir

-----Original Message-----
From: Aki Niemi [mailto:[email-masked]]
Sent: Sunday, March 19, 2006 7:50 AM
To: Audet, Francois [SC100:3055:EXCH]
Cc: Elwell, John; Christian Jansson; Srivastava, Samir

Cheers,
Aki