RE: RE: [Sip] SIP and Congestion Safety

["Dean Willis" <dean.willis@softarmor.com>]

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

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

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip