[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sip] MAJOR Open Issue #184: Message size limitations
I've been working through the various possibilities with Henning. Our
conclusion is that any of these redirect-to-tcp mecahnisms are frought
with problems.
Therefore, the proposal is the following:
1. if the request is larger than some threshold (1000 or somehting), you
MUST use TCP (after compression, of course). If the path MTU is known,
you need to use TCP if the request is greater than that value - 300 or so.
2. It is RECOMMENDED to use TCP to communicate with a server when you
know a NAT is in the way.
Point (1) is based on the observation that in most cases, the response
is not substanially larger than the request. This is certainly true for
MESSAGE, BYE. It is not true for OPTIONS, admittedly, but those are not
record-routed and the requests are also ususally small. The main item
will be record-routes, which can be many hundreds of bytes. Therefore,
we leave a bit of buffer space in the threshold to account for that.
Thus, we should be OK. The second point ensures that, if fragmentation
of the response does happen, there hopefully isn't a nat in the way,
since that is the really bad case.
A refinement on this is what will go into bis-06 unless someone has a
really big beef with it.
-Jonathan R.
Henning G. Schulzrinne wrote:
> Dorgham Sisalem wrote:
>
>>Hello,
>> looking at all the complexity of 499 and UDP to TCP transition I am
>> wondering if fragmentation is really worth the trouble. For the case
>> of signaling I hardly imagine the messages will get big enough so as
>> to worry about congestion due to retransmission (just because a SIP
>>
>
> I think the congestion aspect deserves an additional sentence or two.
> Effectively, SIP behaves like TCP with a window size of 1 segment and
> only time-out based retransmission, i.e., the most conservative
> operational mode of TCP. Depending on the RTT estimate, the SIP timers
> will obviously differ, but their growth behavior is also similar.
>
> The main problem is that with fragmentation, SIP may fail completely if
> various NATs and firewalls get in the way. That, in my view, is the
> bigger issue.
>
--
Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue
Chief Scientist First Floor
dynamicsoft East Hanover, NJ 07936
jdrosen@dynamicsoft.com FAX: (973) 952-5050
http://www.jdrosen.net PH: (973) 952-5000
http://www.dynamicsoft.com
_______________________________________________
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