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

From: "Elwell, John" <[email-masked]>
Date: Sun, 19 Mar 2006 20:54:16 +0000

Francois,

It has been difficult to keep track of this very long thread, but I seem to
recall that the evidence suggested a new SIP method would only be quicker
than STUN if it took certain short-cuts and did not involve the normal
processing that would apply to any other SIP request. Then it would not
really be SIP but some other protocol. I agree then it might be marginally
quicker than STUN.

John

> -----Original Message-----
> From: Francois Audet [mailto:[email-masked]] 
> Sent: 18 March 2006 02:08
> To: Elwell, John; Christian Jansson; Samir Srivastava; 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?
> 
> 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