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

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Wed, 2 Jan 2002 16:15:47 -0000

Strictly speaking, there is no compatibility issue with this particular
requirement changing to a MUST. Compatibility does not equal existing
implementations are automatically compliant with new versions of
specification.

There are compatibility issues with what should a proxy/UAC do if it
receives this new response code, as presumably many existing RFC2543
implementations will be totally unable to use TCP/SCTP as an alternative to
UDP in this case.

Note also that the existing bis text does not mandate support of transport
protocols other that UDP at the moment, therefore there will also have to be
a change in the specification in the area of this requirement as well.

Keith

Keith Drage
Lucent Technologies
Tel: +44 1793 776249
Email: [email-masked]

> ----------
> From: 	Juha Heinanen[SMTP:[email-masked]]
> Sent: 	28 December 2001 17:18
> To: 	Scott  Bradner
> Cc: 	[email-masked]; [email-masked]; [email-masked]
> Subject: 	Re: [Sip] MAJOR Open Issue #184: Message size limitations
> 
>  > anyone who is concerned with reliability or with Internet congestion
>  > should also prefer "MUST use TCP for packets larger than 1500" - it
>  > will be hard to convince the IESG that it is OK for the Internet
>  > to not have this a MUST
> 
> scott,
> 
> i'm wasting too much bandwidth on this, but my point att the time has
> been that someone already has convinced IESG not to have MUST there,
> because it is SHOULD in rfc2543.  in some other occasions people on this
> list have said that iesg requires the bis to be backwards compatible
> with rfc2543, but looks like we are now relaxed from that obligation.
> 
> -- juha
> 
> 
> _______________________________________________
> 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
> 

_______________________________________________
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: [email-masked]
Date: Thu, 3 Jan 2002 09:36:21 -0700

> -----Original Message-----
> From: Bobby Sardana [mailto:[email-masked]]
> Sent: Thursday, January 03, 2002 12:32 AM
> To: Juha Heinanen
> Cc: Jonathan Rosenberg; Dean Willis; Michael Thomas; Hearty, John;
> [email-masked]
> From an implementation's perspective, co-orelating responses 
> from different
> transport types can lead to bulky UA implementations.
> 
> A simple methodology, if TCP/UDP support is needed in SIP, would be:
> 
> a. Use the same transport type for all downstream/upstream 
> communication.

 I am NOT in favor of this.  Some network architectures rely on secure
relationships between elements.  The transport used up to that point can't
override that relationship, i.e. expect UDP to work between two proxies that
normally only talk TLS to each other.

> b. When in doubt, use TCP.
> 
> If we are planning to mix request/responses using TCP/UDP, 
> then mandate only one
> and deprecate the other.
> 
> Regards,
> 
> Bobby Sardana.
> [email-masked]
> 
> Juha Heinanen wrote:
> 
> > Bobby Sardana writes:
> >
> >  > Just curious, why can't the 499 be propagated all the 
> way to the UAC with
> >  > no intermediary (proxy) storage of responses? So if the 
> request originated
> >  > as UDP and the UAS cannot handle it, because of size 
> limitations, and
> >  > requires that a TCP request be made, just reject the 
> request and propagate
> >  > it (like some other errors) back to the UAC. The UAC can 
> then originate a
> >  > TCP request.
> >
> > just to ask again, why can't the uas use tcp to send the 
> response even
> > if it got the request using udp?  sip should care what the transport
> > protocol is.
> >
> > -- juha
>

---

From: [email-masked]
Date: Thu, 3 Jan 2002 10:53:52 -0700

Comments inline.

> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Tuesday, January 01, 2002 9:56 PM
> To: Dean Willis
> Cc: Michael Thomas; Hearty, John; [email-masked]; [email-masked]
> 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
> [email-masked]                 FAX: (973) 952-5050
> http://www.jdrosen.net                  PH:  (973) 952-5000
> http://www.dynamicsoft.com
>