[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Sip] MAJOR Open Issue #184: Message size limitations
Comments inline.
> -----Original Message-----
> From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
> Sent: Tuesday, January 01, 2002 9:56 PM
> To: Dean Willis
> Cc: Michael Thomas; Hearty, John; jh@lohi.eng.song.fi; sip@ietf.org
> Subject: Re: [Sip] MAJOR Open Issue #184: Message size limitations
>
>
>
>
> Dean Willis wrote:
>
> > eh, the smallest v4 MTU implementation I've seen was 576 .
> . . which
> > was common on old PPP and SLIP implementations. But even
> so, it can be
> > challenging to fit into 576 . . .
>
>
> I don't think we need to worry about 576. It seems to be OK
> to take the
> ethernet MTU and subtract away the various overheads. I seem
> to recall
> that we did this for IM and arrived at 1280.
>
> Anyway, the interesting question here is handling the case where the
> request whent UDP and the response should go TCP since its above the
> path MTU. This can get a bit complicated.
>
> One of the complications is that proxies are transactional
> entities. So,
> if we take the approach that "when a server has a response
> that is too
> large to send, it returns a specific error response telling
> the client
> to try tcp", this means that the actual response is
> effectively dropped
> on the floor. When the new request arrives over TCP, it will create a
> new transaction and new processing at the proxy, there is no
> easy way to
> correlate them, or for the proxy to know that it needs to now
> send that
> previous response. We could try to do that (after all, we can
> correlate
> CANCEL to INVITE transactions), but its a larger change.
>
> Without the ability to correlate the transactions, I think I
> can prove
> that through an N proxy chain, it will reuqire O(N^2) messages to get
> the final response when this truncation happens. Heres why.
> Consider the
> UAC that is connected to proxy P1, which goes to P2, etc., to
> PN, to the
> UAS. The original request goes all UDP. The UAS can't send
> its response
> over UDP, so its sends the error (say 499 for now). The 499
> goes to PN,
> which now retries over TCP. The response gets to PN, but PN can't
> forward it to PN-1. So, PN returns 499. PN-1 retries over
> TCP. This is a
> new transaction, so PN forwards to the UAS (presumably over TCP this
> time, otherwise we get an INFINITE ping-pong effect!), which
> responds.
> Now, that response goes to PN, to PN-1, which now can't send
> it to PN-2,
> so it returns 499. PN-2 retries, and now that request goes
> all the way
> to the UAS once more..... and there you have O(N^2).
I'll continue to use the 499 example response for now. There is an
assumption above that the proxy receiving the 499 is trying to fix the
problem with a new transaction on a different transport. That assumption is
what is leading to this messy transaction correlation requirement.
I propose the 499 simply be proxied back to the UAC in any case. The
response would then mean that some where along the route to the UAS the
message got too large for the transport to carry. The session wouldn't
succeed, but keeping it simple is better than introducing a bunch of ugly
requirements to try and make the session work. There could be a MAY in the
spec for the UAC to retry with a trimmed down request. If enough users in a
network complain about the problem, the proxy owner causing the 499s could
consider changing their default transport.
There is the possibility this could happen during an established dialog,
and provisions for falling back to the last state would be needed in the
spec, if something does not already exist.
The possibility of a response somehow becomming too large to forward is one
thing that is a problem with this approach. This would not typically
happen, since responses normally get smaller heading towards the UAC.
However, if for example as Christer suggests some kind of header hiding is
done, this could happen, and a 2xx response for example from the UAS could
be turned into a 499. Not sure what would be an appropriate way of dealing
with this, perhaps just let the 2xx time out.
>
> So, I have convinced myself that truncated responses won't
> work unless
> there is a way for a proxy to correlate a new transaction with the
> previous, such that it knows it needs to send the final response it
> meant to send on the previous, but couldn't.
>
> I suppose we could simply include the original transaction ID
> in the new
> request, in some header somewhere. The change to bis of using formal
> transaction IDs in the via branch param makes that feasible.
> I need to
> think about if there are any lurking demons with that approach....
>
> Thanks,
> Jonathan R.
>
>
>
>
> --
> 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 http://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