Subject: [Sip] SIP Congestion Safety Draft Revised

From: "Dean Willis" <[email-masked]>
Date: Mon, 5 Aug 2002 14:02:25 -0500

Based on list feedback and AD directions the SIP transport congestion
safety draft has been revised and resubmitted under a WG title to the
archives and should appear shortly. In the interimn, you may wish to
review:

http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-congestsafe-00.txt
http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-congestsafe-00.html
http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-congestsafe-00.xml

I'd like to ask you to consider the relation to:

http://www.softarmor.com/sipwg/drafts/draft-khartabil-sip-congestionsafe
-ci-00.txt

Specifically, these seem to refer to different aspects of congestion
safety. Is some sort of convergence needed? If so, what and how?

Thanks,

--
Dean Willis

_______________________________________________
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: Ben Campbell <[email-masked]>
Date: Mon, 05 Aug 2002 15:38:09 -0500

Without making judmements on the technical merits of the khartabil draft 
(and on an admittedly quick read) it seems to me that it attempts to 
solve a somewhat different problem than the sip-congestsafe draft. I do 
not think they need to converge, and they may in fact be complementary.

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Thu, 08 Aug 2002 11:36:06 +0300

I have been reading this draft, and I have some questions and comments.

1) In section 4 I found this sentence:

   Proxies not recognizing a
   specific tag or unwilling to support the associated behavior MUST
   reject a request referencing that tag with a 420 response, which has
   the semantic "Unsupported".

   Although I agree with the technical contents, I believe that the 
   normative text (proxy MUST return a 420 response with Unsupported
   header) is already covered in RFC 3261. I think is simply better 
   not to specify the same procedure, and just refer to the actions 
   described in RFC 3261.

2) Section 5 states:

   "Clearly the best thing to do is to use a more sophisticated transport
   protocol (TCP, SCTP, etc.) between P1 and P2, and between each UA and
   its associated proxy.  If this is not feasible, it may be necessary
   to fall back to UDP.  This is especially common in the case of low-
   capacity UAs such as those proposed for 3G wireless systems."

   I disagree with the example of the last sentence. I have been working
   for a while with the 3GPP standardization, and there is no reference
   to an exclusive usage of UDP in either terminals or proxies.

   As a background information, 3GPP TS 24.229 defines the SIP profile
   used by 3GPP. This specification "imports" RFC 3261 and a number of
   other RFCs. This means, that unless some optionality in RFC 3261 is
   made mandatory in 24.229, the text in RFC 3261 applies. Currently,
   there is not mention at all to the transport protocols in 24.229.
   This means that the text in RFC 3261 is applicable as it is.

   RFC 3261 says in section 18:

   All SIP elements MUST implement UDP and TCP. SIP elements MAY
   implement other protocols.

   Conclusion: in 3GPP all the terminals and proxies MUST implement
   TCP and UDP, although they can implement other transport protocols.

   Now, coming back to the draft, I don't see the point of having such
   a long discussion about UAs that can't use TCP, because the case
   does not exist. If a devices is RFC 3261 compliant, it MUST implement
   TCP.

3) The last paragraph in section 5.1 reveals what I consider is an 
   important problem: routing of SIP responses must follow the Via 
   header, and that includes the transport protocol to the receiver
   of the request. This is a big problem, because a UA may send a
   short SIP request, that fits in a UDP packet, but the response
   may be significantly large, and it does not fit in there. It could
   be interesting to have a procedures to do either of these actions:

   a) The UA could signal in the Via header the set of transport
      protocols supported, so that the proxy which forwards the 
      response could freely choose another protocol, if deemed.
   b) The UAS could use the procedures in section 5.3, Proxy
      Rejects Request That Would Require UDP Fragmentation. Note
      that this section should be changed somehow to accommodate
      responses at the UAS, besides requests at the proxy.

4) Although the table in section 6 specifies that the headers
   Proxy-Max-Size and Proxy-Seen-Size applies to 513 responses,
   it does not say to which request the response applies (there 
   are "-" in all the columns, and should be "o". Suggestion:
 
      Header field          where   proxy ACK BYE CAN INV OPT REG 
      ____________________________________________________________
       Proxy-Max-Size         513      a   o   o   o   o   o   o
       Proxy-Seen-Size        513      a   o   o   o   o   o   o

      Header field                        SUB NOT PRA INF UPD MSG REF
      _______________________________________________________________
       Proxy-Max-Size         513          o   o   o   o   o   o   o
       Proxy-Seen-Size        513          o   o   o   o   o   o   o

Regards,

 Miguel

-- 
Miguel-Angel Garcia                     Oy LM Ericsson AB
                                        Jorvas, Finland
mailto:[email-masked]     Phone:  +358 9 299 3553
mailto:[email-masked]        Mobile: +358 40 5140002

---

From: "Eric Burger" <[email-masked]>
Date: Fri, 9 Aug 2002 12:29:04 -0400

The idea that the response may be too big is interesting and will take some
thought.

I was wondering if there is *any* sensible error mechanism.  Consider the
following:

UA -------> Proxy A -------> Proxy B -------> XXX
    small           moderate         too big,
     msg              msg           send back

The UA sends a small message.  Proxy A forwards it, maybe adding a VIA and
other stuff.  Proxy B tries to forward the message, but by adding its VIA's
etc. the message is too big.  Proxy B would then fail the request, setting
Proxy-Max-Size to less than Proxy-Seen-Size.  The problem is that
Proxy-Seen-Size is much larger than what the UA sent, and most likely larger
than what Proxy A sent.  The point is the growth of the message is beyond
the control of the device getting the error message.  Moreover, what is the
poor human at the UA supposed to do?  True, if the error occurs because the
user is sending a large IM, then they know they shouldn't do that.  However,
if the error occurs because of VIA growing or other proxy-inserted headers,
then the problem is entirely beyond the control of the user and probably
beyond their comprehension.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Miguel
A. Garcia
Sent: Thursday, August 08, 2002 4:36 AM
To: Dean Willis; [email-masked]
Cc: [email-masked]
Subject: Re: [Sip] SIP Congestion Safety Draft Revised

2) Section 5 states:

Regards,

 Miguel