Subject: [Sip] Re: draft-ietf-sip-congestsafe-02.txt

From: Scott Lawrence <[email-masked]>
Date: Thu, 06 Nov 2003 09:34:14 -0500

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.

  The proposed 'congestion-managed' option would allow a system to
  send messages that conflict with policy as set by network
  administration at some later point in the message path; to
  illustrate:

    UAC     Proxy       Proxy     Proxy      UAC
     A -----> B --------> C ------> D ------> E

  UAC A sends an INVITE to E with 'Proxy-Require: congestion-managed',
  initially handing it off to Proxy B.  Using normal SIP routing
  mechanisms, that message finds itself in due course at Proxy D
  (the local proxy on E's network).  The administrator of that
  network has (for whatever reason) chosen to configure SIP on that
  network to prefer (or even be limited to) UDP.  This potential
  conflict raises two questions:

   - Why should a user elsewhere in the network (A) be empowered to
     exercise any control of routing policy within the local network
     (E's network)?

   - Why would A want to send a request using this mechanism, given
     that doing so introduces a new potential failure mode, but does
     not improve that chances that this individual request will
     succeed?

  Granted - A acted (as any IETFer would naturally be inclined to
  do) with the best of intentions, with the health of the Internet
  itself in mind.  If everyone did as A did, and all systems
  supported it, the network would be healthier and happier, and SIP
  (along with everything else) would work better.

  BUT.

  If one takes the view of a product manufacturer, or a local
  network administrator - why would you construct or configure your
  system such that lack of support for that new and improved world
  in just one system outside your control would cause your calls to
  fail?  Remember that your only way to make them work when that
  (inevitably) happens is to resend them without
  'congestion-managed', so you're going to end up potentially
  contributing to congestion problems anyway - but your first
  attempt failed even if no congestion problem actually existed.

  I do think that there is a problem to be solved - I think that the
  draft makes that case well, and has some good rules for system
  developers and administrators on how best to configure systems.
  Rather than a protocol extension, I would prefer to see this work
  redirected to producing a BCP document on how to configure SIP
  requests to prevent congestion problems - the incentives of network
  and SIP administrators are all in alignment there.

-- 
Scott Lawrence        
  Pingtel Corp.   

_______________________________________________
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