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

From: [email-masked]
Date: Thu, 30 Jan 2003 11:01:47 +0530

Hi Dean,

Are you suggesting,in your alternative proposal, that proxies that send
back a 5xx response will not indicate any MTU in it?
If so, then we should also place a restriction that MTU should not be
used as a basis for such an action. Otherwise the originator of the
request will have no clue what is it supposed to do, retry the request
or reduce the size and if so to what value?
However with UDP , MTU does seem a valid basis for preventing
congestion and it may not be possible to place such a restriction.

This is assuming that congestion  due to UDP messages could be
trigerred both due to fragmentation as well as due to a high message
rate.

How about the following?

UA1-------->P1(MTU1)--->P2.......Pn------->UA2(MTU2).

Let checks on MTU be enforced only at the entry and exit points. P1
will reject requests exceeding MTU1, and indicate MTU1 in the 5xx
sent back to UA1. Let the intermediate proxies pass requests without
checking on the MTU of their next hop. At the edge proxy, Pn, let
there be another check based on the max MTU size that UA2 is willing
to accept(such as using the mechanism specified in  Hisham's draft).
That way the second rejection could occur at the edge proxy.
This limits the number of attempts to at most 2, and prevents large
messages from entering the network in the first place.

As an addition, if we want  to allow intermediate proxies to limit
message sizes to the MTUs for the intermediate paths, we might consider
having a mechanism to establish route size for a dialog. Let proxies
not reject messages exceeding the next hop MTU. Agreed that
this does not take care of route dynamicity nor does it take care of
dynamic MTU changes, but attempting to address these issues would
amount to trying to redefine a PMTU discovery mechanism at the
application level.

thanks
Harsh Bhondwe
Hughes Software Systems

Dean Willis <[email-masked]> on 01/24/2003 10:15:14 PM

To:   Harsh Bhondwe/HSSBLR
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.

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

--
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: "Dean Willis" <[email-masked]>
Date: Thu, 30 Jan 2003 12:50:19 -0600

> Hi Dean,
> 
> Are you suggesting,in your alternative proposal, that proxies
> that send back a 5xx response will not indicate any MTU in 
> it? If so, then we should also place a restriction that MTU 
> should not be used as a basis for such an action. Otherwise 
> the originator of the request will have no clue what is it 
> supposed to do, retry the request or reduce the size and if 
> so to what value? However with UDP , MTU does seem a valid 
> basis for preventing congestion and it may not be possible to 
> place such a restriction.

Right. MTU is not a basis in response processing, because responses MUST
follow the path of the request. The comparison factor I'm suggesting is "if
the response is bigger than the request AND the request was not marked
congestion-safe, send a 5XX "cannot respond safely". 

> This is assuming that congestion  due to UDP messages could
> be trigerred both due to fragmentation as well as due to a 
> high message rate.
> 
> How about the following?
> 
> Let checks on MTU be enforced only at the entry and exit
> points. P1 will reject requests exceeding MTU1, and indicate 
> MTU1 in the 5xx sent back to UA1. Let the intermediate 
> proxies pass requests without checking on the MTU of their 
> next hop. At the edge proxy, Pn, let there be another check 
> based on the max MTU size that UA2 is willing to accept(such 
> as using the mechanism specified in  Hisham's draft). That 
> way the second rejection could occur at the edge proxy. This 
> limits the number of attempts to at most 2, and prevents 
> large messages from entering the network in the first place.
> 
> As an addition, if we want  to allow intermediate proxies to
> limit message sizes to the MTUs for the intermediate paths, 
> we might consider having a mechanism to establish route size 
> for a dialog. Let proxies not reject messages exceeding the 
> next hop MTU. Agreed that this does not take care of route 
> dynamicity nor does it take care of dynamic MTU changes, but 
> attempting to address these issues would amount to trying to 
> redefine a PMTU discovery mechanism at the application level.
> 

Your suggestions seem applicable to REQUEST processing, although I don't see
a real gain over the somewhat simpler approach in
draft-ietf-sip-congestsafe-00. The big piece missing from that draft was the
RESPONSE processing. I also continue to worry about path dynamicity. Part of
the difference may be a matter of intent. Personally, I really don't want to
reinvent TCP flow control on top of UDP for SIP. The TCP folks have been
working on that problem for a long time already. I'm more interested in a
way to keep UDP implementations, where we think we MUST have them, from
breaking things.

So, open question -- exactly what is it we're trying to solve here, and how
much mechanism is it reasonable to have?

--
Dean