RE: [Sip] Congestion safety

[hisham.khartabil@nokia.com]

Hi Gonzalo,

While I agree with you about the use of TCP, I still have few concerns:

- How does a terminal decide that a message is large enough to use TCP? How large is large? Would the terminal still use MTU to determine message size?
- RFC3261 recommends using connection oriented protocol if the request is within 200 bytes of MTU, therefore using MTU is nothing new in determining the transport to be used.
- The mechanism in the referenced drafts refers to the situation when the MTU en route is unknown by the UAC. It also doesn't require the UAC to perform an en route MTU discovery. First hop MTU is not enough as we all know.
- Its good that a UAC gets feedback why a message was rejected and how it can make it succeed.
- Message size increases at each hop and the UAC has no idea how large the message will grow as it traverses intermediaries and if it will exceed the MTU or not.
- The use of MTU, as you say, would only be used as an educated guess how large a message size should be. If MTU is 1500, the max size should be set to 1500 - 200 to allow for those extra headers, IP headers etc. (again nothing new here). I can clarify that in the draft is we reach some consensus.

Also, again as you pointed out, the UAC doesn't know the UAS's capabilities, this mechanism can be used regardless of underlying transport protocol so that UAS gets contents indirected. It can then fetch the contents whenever desired (eg: when more memory is available).

Regards,
Hisham

> -----Original Message-----
> From: ext Gonzalo Camarillo [mailtoa:Gonzalo.Camarillo@lmf.ericsson.se]
> Sent: Saturday, October 26, 2002 2:32 PM
> To: sip; Dean Willis; Khartabil Hisham (NMP/Helsinki);
> bcampbell@dynamicsoft.com
> Subject: [Sip] Congestion safety
> 
> 
> Folks,
> 
> I have been reading the two drafts we have about congestion safety.
> 
> http://www.ietf.org/internet-drafts/draft-khartabil-sip-conges
> tionsafe-ci-01.txt
> 
> and
> 
> http://www.ietf.org/internet-drafts/draft-ietf-sip-congestsafe-00.txt
> 
> 
> I believe that trying to control the pace at which a proxy 
> sends request
> is a good idea. Dean and Ben's draft deals with that.
> 
> In addition to that, both drafts try to deal with SIP message 
> size. I am
> not sure that we want to go down this path. Both drafts propose
> application-layer solutions to this problem. However, the SIP 
> layer can
> only make educated guesses about the size of a SIP message
> "on-the-wire".
> 
> Both drafts decide the maximum application-layer message size based on
> the maximum network-layer packet size (MTU). The problem is 
> that between
> the application layer and the network layer you will have things like
> MIP and IPsec that may increase the size of the message and 
> things like
> SigComp that may reduce it.
> 
> IMO, trying to resolve a problem that only applies to legacy systems
> (any future UA/proxy that handles large messages will implement TCP
> and/or SCTP) by providing only approximate solutions is not a 
> good idea.
> And since any complete solution would be too complex, I would suggest
> that we skip solving this issue. If a legacy system needs to 
> be upgraded
> to be congestion safe, it should implement a simple TCP stack (no TCP
> features are needed) rather than implement UDP tricks.
> 
> I realize that the content indirection mechanism proposed by Hisham
> could be used regardless of the MTU... but that's another story.
> 
> Comments?
> 
> Gonzalo
> _______________________________________________
> 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
> 
_______________________________________________
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