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

From: [email-masked]
Date: Fri, 7 Nov 2003 15:42:37 +0200

Hi Dean,

Inline.

 > -----Original Message-----
 > From: [email-masked] [mailto:[email-masked]]On Behalf Of ext
 > Dean Willis
 > Sent: 06 November, 2003 23:11
 > To: [email-masked]; [email-masked]
 > Subject: Consensus on direction needed (was Re: [Sip]
 > Re:draft-ietf-sip-congestsafe-02.txt)]
 > 
 > 
 > 
 > 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.
 > 
 > . . . 
 > 
 > 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). 

Which UDP stuff?

My recollection of this problem and how this work on congest-safe came about in the first place is mainly that in RFC 3428, there are strict size limits for sending a message. These limits can be circumvented only by knowledge that the entire path that the message takes uses TCP (or other congestion controlled transport). Currently, there is no other way to know this, except by administration, and that only works in closed environments. 

The problem that lead to this restriction as I remember it is that per RFC 3261 Ch 18.1.1., in the SIP transport layer, if the size of a message exceeds path MTU (or 1300 bytes when the path MTU for the next hop is unknown) the request MUST always be sent using TCP or similar congestion controlled protocol. But, there is an unfortunate exception to this rule in taking into consideration backwards compatibility with RFC 2543 implementations - if the TCP connection fails or is not there, the request may be retried using UDP.

I think what we really want to do is deprecate *this* behavior.
 
 > 2) Leave the UDP stuff in place, but give people tools to 
 > keep it from
 > being used (which this draft suggests).

Assuming the above is the "UDP stuff" then I agree. However, I agree that documenting the congestion problems in SIP in general is a good idea, and a BCP therefore makes sense as suggested in 1).  
 
 > 3) Rev the spec to 3.0 and rip UDP out by the toenails.

Well... ;)

 > Any other ideas? What is the right thing to do here?

I think we should separate these two things here. First, we have the general congestion-safetyness of SIP to worry about, and as people have already pointed out, a BCP discussing the options in mitigating those concerns is a good idea. 

Secondly, we have the harmful "if-TCP-fails-then-fall-back-to-UDP" behavior, which we want to deprecate and in the mean time hack a fix around it.

Cheers,
Aki

 > --
 > Dean
 > 
 > _______________________________________________
 > 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: Scott Lawrence <[email-masked]>
Date: Fri, 07 Nov 2003 09:50:39 -0500

<[email-masked]> writes:

> Secondly, we have the harmful "if-TCP-fails-then-fall-back-to-UDP"
> behavior, which we want to deprecate and in the mean time hack a fix
> around it.

but it isn't just that - we have placed the control of which transport
is used _explicitly_ in the hands of the user.  Having done that, our
only recourse now as vendors is to make the TCP alternative more
attractive to them than UDP.

-- 
Scott Lawrence        
  Pingtel Corp.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 08 Nov 2003 02:50:19 -0500

> attractive to them than UDP.

The spec is pretty clear on the behavior for large packets:

If a request is within 200 bytes of the path MTU, or if it is larger
    than 1300 bytes and the path MTU is unknown, the request MUST be sent
    using an RFC 2914 [43] congestion controlled transport protocol, such
    as TCP.

this is not leaving it the hands of the user at all. The problem, as 
Aki has pointed out, is the exception clause in the paragraph that 
follows. Indeed, I would go so far is to say that this isnt the 
problem either. Practically speaking, most implementations are rfc3261 
compliant by now - or so they say. The issue is that many 
implementations are rfc3261 compliant, but have chosen not to 
implement or support tcp. No doubt this is in part due to the 
perceived complexities of tcp (some of which are real - large scale 
connection management is hard). There is also the lack of 
specification on properly doing connection reuse, which we are also 
addressing.

As such, there are really two separate problems here. One is getting 
people to use tcp, because we think its better. The second is being 
able to verify, in any particular request, that it really is being 
sent over congestion controlled transports. Mostly this would be for 
rfc3428 implementations that want to send a big message.

Solving the first problem, is done by a combination of the bcp, along 
with connection-reuse getting wrapped, as Scott has suggested. Dean's 
draft addresses the second. I would anticipate that this mechanism 
would be used infrequently, if ever. Since messaging sessions is 
getting close to done, that would be our preferred mechanism for large 
messages anyway.

There isn't going to be a SIP/3.0 - certainly not one that isnt 
backwards compatible. We don't get that kind of luxury in protocol 
design, not for ones that achieve any amount of success at least. So, 
since it needs to be backwards compatible anyway, we are right back to 
where we started from, and thus there is no point in a rev of the spec 
number.

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com