Subject: [Sip] Congestion safety

From: Gonzalo Camarillo <[email-masked]>
Date: Sat, 26 Oct 2002 14:32:20 +0300

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 [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Dean Willis <[email-masked]>
Date: 29 Oct 2002 14:05:22 -0600

Ok, I think you're saying that providing 

   1) a way to detect not-congestion-safe links 
   2) pacing transmissions over not-congestion-safe 
      links so as to avoid overlap 

are an adequate solution, making

   3) Avoiding fragmentation over not-congestion-safe links 

unnecessarily complex.

Inasmuch as solving message-size issues appears to be intractable, I
concur.

Do we have consensus on this in the WG?

--
Dean

---

From: Ben Campbell <[email-masked]>
Date: Tue, 29 Oct 2002 15:28:02 -0600

I concur.