Subject: RE: RE: [Sip] SIP and Congestion Safety

From: [email-masked]
Date: Fri, 24 Jan 2003 19:34:41 +0530

Hi,

I'm assuming that it won't be possible , for various reasons,
to deprecate UDP. Therefore even though it may not be possible
to assure 100% congestion safety when UDP is used, some
mechanisms such as those already presented in 2 existing drafts
may be used to prevent congestion to some extent.

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.

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.

Comments?

thanks
Harsh

[email-masked] on 01/22/2003 08:14:23 PM

To:   [email-masked], [email-masked]
cc:    (bcc: Harsh Bhondwe/HSSBLR)

Subject:  RE: RE: [Sip] SIP and Congestion Safety

> -----Original Message-----
> 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

>
>
>
>
>
> Sal
>
>
> > Please take a look at
> >
> >
> http://www.ietf.org/internet-drafts/draft-khartabil-sip-conges
> tionsafe-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,
> > >
> > > 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
> > _______________________________________________
> > 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
> >
>
>  Per registrarti gratuitamente a Vodafone Mail vai su www.190.it
>
>
>
_______________________________________________
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: Dean Willis <[email-masked]>
Date: 24 Jan 2003 10:45:14 -0600

> 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.

> response, instead of having to converge on a value

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?

--
Dean