Folks,
I have been reading the two drafts we have about congestion safety.
http://www.ietf.org/internet-drafts/draft-khartabil-sip-congestionsafe-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