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

From: "Christian Jansson" <[email-masked]>
Date: Thu, 16 Mar 2006 22:50:22 +0100

(Real comment about the subject below ***************)

It is interesting to study the design of the 3 protocols (SIP/SDP/STUN)
that we currently use.

SIP:
In SIP anything is possible, you can write your code kind of anyway you
want and that should be possible to parse on the other side. I guess SIP
is the hippie version of a protocol. No space, many spaces, tabs or no
tabs, case-sensitive or case-insensitive, line folding or not, compact
form or not compact form, multi value headers and single value headers,
name-addr or addr-spec. The most important design principle behind SIP
seems to be that the headers can be made to look nice to the human eye.
And never decide on just one way of expressing something when there is a
possibility that something can be done in more than one way.

SDP:
SDP is no mr. nice guy when it comes to letting the programmer has his
artistic touch affect the look of the messages. The line comes in a
strict order v, o, s, ...., no extra spaces allowed, period. Do not even
dare to mention \t. Compared to the hippie SIP, SDP is the protocol
fascist.

STUN:
So we had SIP that was perfectly readable for the human eye (but..
hrmmmff a bit more complicated than necessary ..hrrmmff.... for a
computer parser), and we had SDP, that was strict and easy to parse but
still being human readable. But why not invent a new protocol again :)
This time the design principle was performance and size, but
importantly, not without being impossible to extend. 

I never seem to stop wondering why the design principle behind SIP never
had performance as a big issue. The most important thing seemed to be
that it looked like HTTP, ... even though it wasn't HTTP. And a lot of
things with SIP seems to want to look like something even though they
really arn't. SBCs and transparent B2BUAs wants to look like proxies,
... even though they aren't. And now someone is suggesting we create a
PING request that looks like a SIP message but in fact isn't one. Maybe
we should write a draft in this WG that explains the difference between
"is a" and "sometimes looks like a".

*********************

If anyone gets this far I can at least give my opinion about the current
subject:

IF we would chose SIP as the protocol for the keep-alive task, let's not
overload OPTIONS. OPTIONS already has a task and let's not give it
another one that it was not designed for when we have so many other
letters in the ASCII set. Haven't we had enough of trying to overload
things in SIP (Maybe we could use INFO for the keep-alives.... that
would be ....)

IF we are saying (in other threads) that SIP over UDP is probably a
really bad idea and should perhaps be deprecated, why would it be seen
as an advantage to let TCP have the same keep-alives (STUN) as that of
another problematic protocol?

/ 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

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 17 Mar 2006 13:56:47 +0000

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
> 
>

---

From: "Samir Srivastava" <[email-masked]>
Date: Sun, 19 Mar 2006 21:21:11 -0600

Hi Jeroen,

I understand your concerns that SIP MIB should not be constraint in
implementing optimized signaling  features. I am just trying to see how
it will fit in the forthcoming overload/congestion solutions. 

SIP MIB has applIndex also, which looks  to me SIP Server / Port. Excuse
my less knowledge of SIP MIB. It captures the SIP method stats per
method and per application. SIP MIB authors pl comment.

My requirement is, I need to find out the KEEP ALIVE traffic in MIB.
CR-LF is not a SIP method, So it's stat will not captured there. And I
don't have any way to find out that using existing MIB's.

There is one  more available choice. I am listing all below again for
the feedback 

1) Define STUN MIB. (Does it exist, I don't see it on the behave page)
Should be taken in behave. If there is enough momentum from other STUN
users, then it is worth taking it. Design wise, it is right place to
capture CR-LF stats. I have another fundamental design issue, STUN MIB
needs to able differentiate SIP port NAT binding Keep Alive traffic from
other STUN traffic. It will be taking more time in developing new MIB,
and SIP overload / congestion framework will be dependent on that too.

2) 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.

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

4) Have PING method (which purist doesn't like) but it can be done with
least pain and quickly.

Thx
Samir

-----Original Message-----
From: Jeroen van Bemmel [mailto:[email-masked]] 
Sent: Sunday, March 19, 2006 2:06 PM
To: Srivastava, Samir [SC100:8826:EXCH]; Aki Niemi; Audet, Francois
[SC100:3055:EXCH]
Cc: Cullen Jennings; [email-masked]; Christer Holmberg (JO/LMF); Elwell,
John
Subject: Re: [Sip] Myth Busters: Episode 1,Is STUN
requestprocessingfaste r than a SIP PING request processing?

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?

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.
>
>> 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
>>
>>> To: Samir Srivastava; Cullen Jennings; Christer Holmberg (JO/LMF); 
>>> Hisham Khartabil; [email-masked]
>>>> Another point  "Every application protocol should take of its own 
>>>> mess using its own primitives" .
>>> RTP? In general I think it is better to use a tool that is designed 
>>> for the problem.
>>>
>> 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.
>>>
>>> 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.

>>> 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
>>>
>>>
>>> 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
>>>
>> 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
>>
>>
>
> 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