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

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 27 Dec 2001 02:28:48 -0500

inline.

Henning G. Schulzrinne wrote:

> Michael Thomas wrote:
> 
>>Jonathan Rosenberg writes:
>> > 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.
>>
>>   I do not understand why this should be a problem given
>>   a reasonable implementation. Fixed sized fields suck;
>>   lets not go there.
>>
> 
> Plus, it's very hard to know what to do. "Dear Mr. Schulzrinne, please
> shorten your name since your SIP message is too long?"
> 
> 
>> > 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.
>>
>>   I would be highly *unsupportive* of 1 or 2. Beyond that
>>   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).

There was some discussion of this issue with Allison in an offline 
conversation. The result of that discussion was that your variation was 
a reasonable direction, similar to DNS. Specifically:

1. if the request is larger than 1500 bytes, you MUST use TCP to send it,
2. if the request came over udp, but the response is longer than 1500, 
you send a specific error response code which says "response is too big 
to go over udp, please retry request with tcp", and then proceed.

Achieving point 2 above in SIP will require a new response code, which 
is no big deal. However, it will only work properly if (1) proxies have 
the ability to resubmit a request to a next hop without changing 
anything but the via header [should be ok with bis proxies, may be a 
problem with rfc2543] (2) proxies don't add anything to responses as 
they get forwarded. This second point is tough. Here's why its needed. 
Lets say the UAS sends a 200 OK. Proxy gets it. Its GOT to forward it, 
but can't, since it added something, and now its too big to send over 
UDP. It can't just drop it, but it can't forward it either.

This particular solution would also require all UAs to support TCP in 
addition to UDP. It wouldn't always get used, but would have to be there.

Comments?

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email-masked]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (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: Juha Heinanen <[email-masked]>
Date: Thu, 27 Dec 2001 10:09:52 +0200

> to go over udp, please retry request with tcp", and then proceed.

i don't think dns has anything like this.  instead dns servers and
resolvers are asked to support large size udp messages, see
draft-ietf-dnsext-message-size-04.txt.  a mixed mode behavious sounds
like a bad idea.

-- juha

---

From: Jim Reid <[email-masked]>
Date: Thu, 27 Dec 2001 01:11:05 -0800

>>>>> "Juha" == Juha Heinanen <[email-masked]> writes:

    >> There was some discussion of this issue with Allison in an
    >> offline conversation. The result of that discussion was that
    >> your variation was a reasonable direction, similar to
    >> DNS. Specifically:
    >> 
    >> 1. if the request is larger than 1500 bytes, you MUST use TCP
    >> to send it, 2. if the request came over udp, but the response
    >> is longer than 1500, you send a specific error response code
    >> which says "response is too big to go over udp, please retry
    >> request with tcp", and then proceed.

    Juha> i don't think dns has anything like this.  instead dns
    Juha> servers and resolvers are asked to support large size udp
    Juha> messages, see draft-ietf-dnsext-message-size-04.txt.  

The original poster is correct. This is *exactly* how DNS works. There
is an enormous installed base of stub resolvers and name servers that
only implement the current 512-byte payload over UDP and then TCP
retry on a truncated response. This won't be going away any time soon.
The above draft simply advocates the use of an existing protocol,
EDNS0, which has been done that allows for bigger UDP packets. It's
implemented in BIND9, though this isn't yet widely deployed. Even if
EDNS0 is everywhere, truncation and TCP retries will still occur,
albeit less frequently.

IMO, we should try to keep SIP simple. Set a reasonably large packet
size for UDP that should be "big enough" for the expected data. Then
allow TCP retries if/when that limit is exceeded. The trick will be
deciding how much is big enough and trading off arbitrary limits with
network/data fragmentation issues. That's how we got the 512 byte
limit in DNS. In the old days a 576 byte datagram (64 bytes of headers
and 512 bytes of data) was the maximum packet size that was guaranteed
to be sent across the net without getting fragmented.

---

From: Howard Hart <[email-masked]>
Date: Thu, 27 Dec 2001 10:57:00 -0800

Right. Maybe as simple as following RFC 2181, Section 9, and just
substitute Jonathan's error response code for the Truncated header bit
used to flag oversize UDP messages in DNS.

Howard Hart
ipDialog, Inc.