Subject: [Sip] SIP and Congestion Safety

From: [email-masked]
Date: Mon, 20 Jan 2003 18:55:13 +0100

Hi all,

about SIP and Congetion Safety, i've observed there isn't a great interest.

I don't know why.
I think that will be a giant problem. 

And the mainly question for it is: what protocol use for transport SIP signals ???

others wg in IETF are working about congestion control algorithms for real-time 
or, more  generally,  delay sensitive applications... 
see DCCP (Datagram Congestion Control Protocol  -  http://www.ietf.org/html.charters/dccp-charter.html).

sometime ago there was a proposal about  SCTP use for Instant Messaging with SIP...

in other mail i read a proposal about Connection Transport Protocol as default protocol for SIP

in the "Session Initiation Protocol Extension to Assure Congestion Safety" draft-ietf-sip-congestsafe-00
there's only a proposal for define and check a CONGESTION-SAFE hop... but it isn't enough 

Sal
_______________________________________________
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: [email-masked]
Date: Tue, 21 Jan 2003 10:59:06 +0200

Please take a look at

http://www.ietf.org/internet-drafts/draft-khartabil-sip-congestionsafe-ci-01.txt

I'm planning to update this to include a UA posting (eg: contents for PUBLISH or MESSAGE).

Regards,
Hisham

> -----Original Message-----
> From: ext [email-masked] [mailto:[email-masked]]
> Sent: Monday, January 20, 2003 7:55 PM
> To: [email-masked]
> Subject: [Sip] SIP and Congestion Safety
> 
> 
> 
> Hi all,
> 
> see DCCP (Datagram Congestion Control Protocol  -  
http://www.ietf.org/html.charters/dccp-charter.html).

Sal

---

From: [email-masked]
Date: Wed, 22 Jan 2003 16:44:23 +0200

> From: ext [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, January 22, 2003 10:31 AM
> To: Khartabil Hisham (NMP/Helsinki); [email-masked]
> Subject: Ri: RE: [Sip] SIP and Congestion Safety
> 
> 
> 
> Hi Hisham,
> 
> I've read your draft "draft-khartabil-sip-congestionsafe-ci-01.txt"
> It's an interesting draft, but not cover all my questions.
> 
> In any case about your draft i've some observations:
> 
> in the section -5.0-
> You write that the proxy affect for Congestion Safe in 3GPP 
> architecture is S-CSCF.
> I think that P-CSCF is the most critical Proxy.
> This one is the closest proxy to the UA. And in a Visited UA
> scenario, I think that it's preferable, for an Operator 3G, 
> not forward information about his link capacity to another 
> Operator 3G.

The document does say "the S-CSCF closest to the UA". I think the use of the word "home" confused you.

> Morover I think that are also performance problem for which 
> P-CSCF have know information about Max-Size SIP message that 
> UAS can handle.

Perhaps, but to my knowledge, S-CSCFs have the intelligence. P-CSCFs are nothing but outbound proxies to the sending UA.

In any case, where 3GPP decides to put the intelligence is out of the scope of this document. The sentence you refer to is just an example (and perhaps should be removed).

> 
> In the section 5.5. "Home Proxy Receiving 413 Response from UA"
> What's advantage  for a UA to reject a request, also if is a 
> large SIP request, when it's already received? When arrived 
> to UA, the large message already has congestioned the link.
> 
> The main problem is avoided and prevent the congestion link.

The solution is not just limited to the congestion of the network, it also tries to handle out-of-memory situations for a terminal, even when using TCP. If a terminal is receiving TCP packets for a sip message and knows it can't handle anymore packets, it can stop receiving and send 413 error response.

Regards,
Hisham

> > in the "Session Initiation Protocol Extension to Assure 
> Congestion Safety" draft-ietf-sip-congestsafe-00
> > there's only a proposal for define and check a 
> CONGESTION-SAFE hop... but it isn't enough 
> > 
> > 
> > Sal
>  Per registrarti gratuitamente a Vodafone Mail vai su www.190.it 
> 
> 
>

---

From: [email-masked]
Date: Fri, 24 Jan 2003 19:37:48 +0200

> From: ext Dean Willis [mailto:[email-masked]]
> Sent: Friday, January 24, 2003 6:45 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: RE: RE: [Sip] SIP and Congestion Safety
> 
> 
> On Fri, 2003-01-24 at 08:04, [email-masked] wrote:
> > Both the drafts(draft-khartabil-sip-congestionsafe-ci-01.txt
> > and draft-ietf-sip-congestsafe-00) propose using a max-size
> > header to indicate to the previous hop SIP entity the max
> > size that it(the SIP entity sending the 403, 503 response)
> > would allow on the next hop. Both the drats also assume that
> > the proxies know the MTU of the next hop by some means.
> > 
> > Its not very difficult to encounter the following problem
> > in this mechanism:
> > 
> UA1--(MTU1)--P1--(MTU2)---P2--(MTU3)--P3--(MTU4)--P4--(MTU5)--
> P5--(MTU6)--U
> > A2
> > 
> > MTU1>MTU2>MTU3>MTU4>MTU5>MTU6
> > 
> > In such a case it might take UA1, 6 attempts to finally
> > get a request through to UA2. And since the MTU for a
> > link is dynamic this could get even worse.
> 
> yep. Actually, it's worse than that, since as you point out it is
> possible for dynamic rerouting to occur.  That makes the 
> absolute worst
> case even more entertaining. Assuming that every reduction reduces the
> size of the message by 1 byte, then the worst case number of 
> retries is
> given by the equation Size(Max) - Size(Min), where Max is the largest
> message ever sent, and Min is the smallest MTU allowed. 
> Assuming common
> values of 1300 and 576, that gives us more than 700 retries before a
> message gets through. But at least it's deterministic.

I believe the drafts do say the max MTU en route to the UAS. How that en route is discovered is outside the scope of sip, IMO.

> 
> 
> > Considering such a scenario, I was wondering if it might be
> > a good idea to adopt a mechanism similar to the one used
> > for the session timer, i.e allow proxies in the path to
> > insert or update a min MTU similar to the way the session
> > timer value is inserted/updated. Proxies need not reject
> > requests that exceed the MTU of the next hop(hence
> > avoiding the problem enumurated above). And like with
> > session timer, the UA that initiated the request would
> > get to know the min MTU for the complete path in the
> > response, instead of having to converge on a value
> > through trial and error.
> 
> 
> If I understand this, you're proposing that we complete one round-trip
> in order to establish a route size for future use within the 
> dialog, and
> that we assume that the route does not vary over the course of the
> dialog.
>  
> The main problem here -- what if the first request is 64kB long and
> blows up on the UDP network just past the first proxy?
> 
> And of course, there's the problem of route dynamicity.
> 
> Here's an alternative proposal. Rather than negotiating size, could we
> "just say no"?
> 
> Any proxy that finds it cannot congestion-safely transmit a message
> simply kicks back a 5xx "cannot send safely" response, and it's up to
> the sender to find another route?

What's wrong with content indirection?

/Hisham

> --
> Dean