Subject: RE: Consensus on direction needed (was Re: [Sip] Re: draft-ietf-s ip-congestsafe-02.txt)]

From: Gordon Ledgard <[email-masked]>
Date: Thu, 6 Nov 2003 16:58:26 -0500

>> On Thu, 2003-11-06 at 08:34, Scott Lawrence wrote:
>>   This draft presents an excellent explanation of how and why the
>>   use of UDP in SIP can (and therefor by Murphys Law, will :-) cause
>>   network operation problems.  In doing so, it makes a good case for
>>   SIP having been designed differently, possibly not using UDP at
>>   all, but acknowleges that it is too late for that.  It goes on to
>>   propose mechanisms by which this oversight can now be corrected by
>>   defining a congestion-safe mode of operation and adding a protocol
>>   feature to require operation in that mode.
>>
>>  Unfortunately, I don't think that creating such a mechanism is
>>   useful, because there is little or no incentive for any
>>  significant number of systems to use it.  The cat is not only out
>>  of the bag in that SIP was designed to support UDP, but later
>>  standards (SIP use of NAPTR and DNSSRV in RFC 3263) have provided
>>  for explicit administrative control mechanisms by which users
>>  (administrators) can (perhaps unwisely) prefer the use of UDP.

On Thu, 2003-11-06 at 16:12, Dean Willis wrote:

> Excellent summary and commentary.
> 
> Here's the deal. Before long, EVERY e2e-secured SIP request or response
> is going to be bigger than one packet. The security people aren't going
> to give up on e2e.
> 
> This gives us two viable alternatives, as I see them:
> 
> 1) Deprecate UDP usage in SIP.
> 
> 2) Deprecate SIP.
> 
> Since #2 would leave me unemployed :-(, the question I'm interested is
> how to do #1.
> 
> Three possibilities suggest themselves, and I'd like to get a sense of
> consensus from the group on the direction (or other suggestions, if
> there are any).
> 
> 1) Leave the UDP stuff in place, but convince people not to use it by
> doing a "UDP Considered Harmful for SIP" BCP,  (which Scott seems to be
> suggesting). 
> 
> 2) Leave the UDP stuff in place, but give people tools to keep it from
> being used (which this draft suggests).
> 
> 3) Rev the spec to 3.0 and rip UDP out by the toenails.
> 
> Any other ideas? What is the right thing to do here?
> 
> --
> Dean

You could always leave the current definition of SIP alone, and
define a new version of it (call it SIPNEW or something?) that
uses non-UDP transports to support e2e. Why deprecate the old
one if people find it useful for certain problems? You could just 
mandate that old SIP cannot be used in e2e environments, and that
if e2e is ever required for your application, you need to use
the newer SIP.

I've long been of the opinion that there needs to be two flavors of
SIP, one for secured proprietary networks, and one for the internet
at large. (Don't flame me! I understand the current mandate of SIP.
I'm just saying it might be useful.) The motivation for the simpler
SIP would be to improve speed and cut down on message bloat.

Gordon

_______________________________________________
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: Scott Lawrence <[email-masked]>
Date: Thu, 06 Nov 2003 18:31:13 -0500

> if e2e is ever required for your application, you need to use

e2e is not required to cause the congestion-related bad behaviour of
SIP; large messages are not even required.  All that's required is
_something_ that causes packet loss on links that are already running
at a load close enough to capacity, somewhere in the path - after
that, the retransmissions push the network into collapse.

-- 
Scott Lawrence        
  Pingtel Corp.