Subject: [Sip] MAJOR Open Issue #184: Message size limitations

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 6 Dec 2001 01:44:49 -0500

Issue:

There are a bunch of issues relating to message sizes. 

1. The spec says a request SHOULD NOT be larger than the path MTU. However,
we are no frequently seeing that with SIP messages in larger SIP networks
with several proxies that are record-routing. This is allowed, since you
have to be able to accept requests larger than the MTU, but results in IP
fragmentation for UDP, which is really, really, really, really bad for many
reasons.

2. The spec imposes no specific limits on the sizes of various headers, or
the number of each type of header. However, many implementations have chosen
their own limitations, often based on a guess, in order to allocate maximum
buffer sizes and the like. This has resulted in some interoperability
problems. Ideally, we should allow any number of each header, and any size
for any element, up to the maximum allowed SIP message size (64k), but this
is not realistic.

Discussion:

There are no simple solutions to these problems. For the first problem, some
of the solutions include:

1. deprecate UDP; use only TCP or SCTP for SIP
2. deprecate UDP for server to server, only allow it client to server. 
3. define sip layer fragmentation
4. ignore the problem

(4) is not so unreasonable, in fact. Assuming messages don't get THAT much
larger, we will usually see two fragments, which isn't too bad from a loss
amplification perspective. It is a problem for NAT, but if you assume NAT is
client to server only, and users are using TCP there anyway, its solved. Not
ideal, but none of the solutions is.

For the second problem:

1. impose no limits
2. for each parameter and header, define some kind of limit, recognizing we
may find we have shot ourselves in the foot down the road for choosing wrong
3. ignore the problem

None of these seem particularly appealing either.

Proposal:

THis is the one issue for which I have no proposals. All solutions seem
unacceptable to me. Any good ideas out there?

-Jonathan R.

---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
Sip mailing list  http://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: Michael Thomas <[email-masked]>
Date: Thu, 6 Dec 2001 09:53:31 -0800 (PST)

> for any element, up to the maximum allowed SIP message size (64k), but this

   I do not understand why this should be a problem given
   a reasonable implementation. Fixed sized fields suck;
   lets not go there. 

 > ideal, but none of the solutions is.

   I would be highly *unsupportive* of 1 or 2. Beyond that
   I'm not sure. Compression may be our friend here.

	   Mike

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Thu, 06 Dec 2001 13:12:10 -0500

>    a reasonable implementation. Fixed sized fields suck;

Plus, it's very hard to know what to do. "Dear Mr. Schulzrinne, please
shorten your name since your SIP message is too long?"

>    I'm not sure. Compression may be our friend here.

Agreed; there is very little precedence for this type of limitation in
822/HTTP-style protocols. (Yes, I realize that they don't do UDP,
either.) RFC 2822 does limit the size of a line to 998 characters, but
this is an historical accident.

Limiting messages sizes also invites people to just test their code with
that message size. Code Red is the consequence. (Well, the authors of
that code didn't need the excuse of limited message sizes.)

I would vote for (4). If we really want to add bytes to the spec, we
could make motherhood-and-apple-pie statements about not wasting bytes,
but that seems silly.

One variation on a solution is to have servers use TCP or similar if the
message is long. This doesn't work if only the response is long, not the
request, but usually, the two sizes seem to be closely correlated (e.g.,
because of the number of SDP lines in the request).
-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs