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

From: "Paul E. Jones" <[email-masked]>
Date: Tue, 1 Jan 2002 22:02:15 -0500

The 576 comes from the IP standard itself... so the smallest should indeed
be 576 (see RFC 791).

However, I agree that the 1500 bytes is not written in stone.  This is a
recommended value for some topologies, but it may certainly be higher or
lower.  Some people are doing PPPoE, which results in a lower MTU in most
(or all?) cases.

However, I would not necessarily agree with the requirement that a device
use TCP if the packets are larger than 1500 octets.  I suppose that this a
reasonable request to be imposed on the calling device, but what about the
called device?  What if it needs/wants (for whatever reason) to send a 2000
octet packet when the calling endpoint initiated a call via UDP?  If the
selection of the transport protocol is left to the calling endpoint, it
seems that you've gained little by adding the requirement.  I think the only
reasonable thing to do is state the problem and leave it for the
implementers to handle as they see fit for their particular application.

Paul

----- Original Message -----
From: "Dean Willis" <[email-masked]>
To: "Michael Thomas" <[email-masked]>; "Jonathan Rosenberg"
<[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Monday, December 31, 2001 12:07 PM
Subject: Re: [Sip] MAJOR Open Issue #184: Message size limitations

>
> 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  . . .
>
> --
> Dean
>
>
>
> On Friday 28 December 2001 03:20 pm, Michael Thomas wrote:
> > Jonathan Rosenberg writes:
> >  > I would still prefer "MUST" use TCP for packets larger than 1500;
> >  > your existing devices will be non-compliant (good motivation to
> >  > fix it) but will still function; I think its fair to say that you
> >  > still need to be able to receive UDP packets larger than 1500.
> >
> >    Something that needs to be brought up here is that
> >    1500 is a fictitious number. Strictly speaking, it's
> >    more like 256 or so for IP4 and 1280 for IP6. I'm
> >    not sure we want to go with the IP4 strictness, but
> >    those are your only guarantees with PMTU.
> >
> >      Mike
> >
> > _______________________________________________
> > 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
>

_______________________________________________
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: Jonathan Rosenberg <[email-masked]>
Date: Tue, 01 Jan 2002 23:56:24 -0500

> 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).

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

---

From: Bobby Sardana <[email-masked]>
Date: Tue, 01 Jan 2002 22:01:24 -0800

Greetings all:

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.

Regards,

Bobby Sardana.
[email-masked]

---

From: Juha Heinanen <[email-masked]>
Date: Wed, 2 Jan 2002 08:57:27 +0200

> meant to send on the previous, but couldn't.

i thought that a stateless proxy doesn't need to correlate anything, but
just to route messages to the next hop.

what would the problem be if any entity can freely choose to use either
udp or tcp to send a message no matter what protocol possible other
messages of that transaction were using?

-- juha

---

From: Juha Heinanen <[email-masked]>
Date: Wed, 2 Jan 2002 09:00:47 +0200

> it (like some other errors) back to the UAC. The UAC can then originate a

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: Juha Heinanen <[email-masked]>
Date: Wed, 2 Jan 2002 10:19:56 +0200

i agree with christer in that 499 will mess things up very badly.  if we
can't make sip transport independent, i.e., the *sip* entity should not
care how it got a message, then it was a mistake to allow udp in the
first place and we should deprecate it.

-- juha

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 02 Jan 2002 10:03:37 +0200

Hi,

First, how would all this work with forking?

Assume the following case:

UAC_1 sends an INVITE using UDP, which is forked by P_2.

UAS_3 receives the INVITE, accepts it and returns a provisional- or 200
response.

UAS_4 also receives the INVITE, but wants to use TCP, so it returns 499.

Now, when UAC_1 receives the responses, what is it supposed to do? Keep
the UDP transaction with UAS_3 alive, and generate a NEW TCP transaction
with UAS_4???? Or, is it supposed to terminate (using a tagged BYE) the
leg with UAS_3, and initiate a new INVITE using TCP, which again will be
forked to both UAS_3 and UAS_4????

And, will there be any tags in the 499 which UAC_1 is supposed to use?
Otherwise the new INVITE transaction using TCP may be forked to both
UAS_4 and UAS_3, which would mess up UAS_3 if the UDP leg was NOT
terminated...

Second, if we change the transport protocol in the middle of the
transaction (Juha's proposal), how would that affect security, eg if
IPSEC is used?

Third, I am NOT proposing the remove UDP, but my question is: if we have
an application (in our case SIP) which have specific requirements on the
transport protocol, and the transport protocol (in our case UDP) can't
provide those: why use that transport protocol in the first
place???????? Also, how will SCPT affect all this????

My PERSONAL opinion is that what we are doing now (499 response codes,
change of transport protocols in the middle of a transaction etc etc
etc) is going to mess up, and slow down, things pretty BAD - and it's
going to make SIP everything but simple and transport independent (I am
NOT saying that we don't have a problem to solve...)... 

Regards,

Christer Holmberg
Ericsson Finland

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 02 Jan 2002 10:12:57 +0200

Hi John,

Are you talking about fragmentation on the SIP level, or on the IP/UDP
level? I assume you talk about the IP/UDP level, and in that case I
don't understand what the SIP application has to do with it. The SIP
application shouldn't care if IP packages are fragmented (after all,
even if the SIP node itself doesn't do fragmentation, packages may be
fragmented by intermediate routers anyway...).

If fragments are lost, the UDP checksum will inform the receiver about
that. And, the reason we have re-transmits when using UDP is to make
sure the receiver will get a "complete" message, in case
messages/fragments are lost in the network...

Regards,

Christer Holmberg 
Ericsson Finland

[email-masked] wrote:
> 
>  Hmmm.  I'd say all your implementations that support reassembling
> fragmented SIP risk problems if there is packet loss.  They are making up
> for non-compliant devices that are fragmenting the SIP messages (see bis-05
> section 7.5).  SIP over unreliable transports should be in one datagram to
> maintain the reliability mechanisms built into SIP.  If you fragment the
> message, the reliability may be lost.
> 
> John Hearty
> Level3
> 
> > -----Original Message-----
> > From: Juha Heinanen [mailto:[email-masked]]
> > Sent: Friday, December 28, 2001 1:18 AM
> > To: [email-masked]
> > i have nothing against introducing an error response for truncated UDP
> > messages, but whatever the new spec will say should not make existing
> > implementations that support large udp packets non-compliant.
> >
> > i have in active use half a dozen different sip phone,
> > proxies and media
> > gateway controllers and all of them today send and receive
> > sip messages
> > in udp packets that are larger than 1500 bytes.  their network driver
> > simply ip fragments and reassembles a packet if it doesn't fit into a
> > 1500 byte ethernet frame.  almost a year ago i found one ip phone that
> > didn't support reception of framented udp packets, but that
> > was promptly
> > fixed, when i reported the issue.
> >
> > if the new version of the spec will say (as jonathan
> > suggested) "if the
> > request is larger than 1500 bytes, you MUST use TCP to send it", then
> > such a statement would make all off-the-shelf sip entities that are
> > currently in use in my network non-compliant, which would be
> > a VERY bad
> > idea.
> >
> > -- juha
> >
> >

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 02 Jan 2002 14:20:45 +0200

Hi,

Regards,

Christer Holmberg
Ericsson Finland

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 02 Jan 2002 14:44:10 +0200

Hi John,

Regards,

Christer Holmberg 
Ericsson Finland

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 02 Jan 2002 15:58:51 +0200

Hi,

>first place and we should deprecate it.

I agree. I think the operator should be able to configure his nodes to
use whatever transport protocol he wants, depending on network
capabilities (maximum UDP size, delay, load etc), media (affects the SDP
message body length) etc etc etc. I do NOT think the spec should define
response codes and complicated rules etc how one must "switch" between
different transport protocols etc. 

The good thing about having a transport independent protocol is that one
can choose the transport mechanism (UDP, TCP, SCTP, whatever is defined
in the future) he wants - so let's keep it that way.

Regards,

Christer Holmberg
Ericsson Finland

---

From: "Dean Willis" <[email-masked]>
Date: Wed, 2 Jan 2002 13:55:14 -0600

The problem is indeed  fragmentation at the UDP level. This has two
confounding effects:

1) If any fragment is lost, the whole SIP message times out and must be
resent. The probability of a drop increases linearly with the fragmentation
ratio. An unfortunate subeffect is that fragments following the first one
are sent anyhow, so the retransmission load is at least 2x the original size
and not the fragment size. This is a Big Bad for the people who are worried
aboutnetwork congestion behavior -- it causes SIP (at least in the sparse
many-many case) to INCREASE network load during lossy conditions rather than
backing off smoothly. Immagine a connection that is running at
near-capacity. A glitch occurs

2) NAT boundaries get a little strange.

--
Dean

----- Original Message -----
From: "Christer Holmberg" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, January 02, 2002 6:44 AM
Subject: Re: [Sip] MAJOR Open Issue #184: Message size limitations

> fragmented by intermediate routers anyway...).

 . . .

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 03 Jan 2002 07:59:04 +0200

Hi,

The solution to the problem you describe is - SIP. If an operator has
the problem with UDP that you describe, either in the whole of his
network or between specific SIP nodes, he may configure the nodes to use
TCP (or SCTP, or whatever) instead of UDP. Again, that's one of the good
things of having a transport independent protocol.

What we are discussing here is if the choise of transport protocol, or
"switching" between transport protocols, should be done on the SIP
application level (and HOW the choise shall be done) or not, and MY
opinion is that it shall not.

Abuot the fragmentation: does anyone have any numbers/statistics how
OFTEN it will occur in a real-network scenario, and how MUCH
congestion/delay it generatas? Also, WHICH messages are fragmented, and
how MANY fragments are genearted? How will SIP compression affect that?
How is it COMPARED to the network load generated by TCP? etc etc etc. I
think there are LOST of questions to answer before doing any "radical"
changes in the spec...

I remember a couple of years ago, when everybody having a "SIP vs H.323"
speech at some conference said that SIP is so great because (among other
things) it can be used with UDP... :)

Regards,

Christer Holmberg
Ericsson Finland

---

From: Bobby Sardana <[email-masked]>
Date: Wed, 02 Jan 2002 23:32:08 -0800

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.
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]

---

From: Bobby Sardana <[email-masked]>
Date: Wed, 02 Jan 2002 23:40:50 -0800

Christer Holmberg wrote:

> ......

SIMPLE secure evolution :-)

regards,

Bobby Sardana.
[email-masked]

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 03 Jan 2002 03:02:37 -0500

> if it got the request using udp?  sip should care what the transport

It does care, since it needs to provide its own reliability for the UDP 
case. Thus, the transaction state machines have timers that are 
sometimes equal to zero for reliable transports.

Sending the response over TCP would therefore:

1. require all client elements to always listen for incoming TCP 
connections, needless to say that will be fun with nat.

2. make the transaction machines more complicated, since they would need 
to deal with a possible change in timer values mid-transaction

I am all for simple solutions, despite what some people think. However, 
I am not sure its just as simple as using TCP to send the response.

-Jonathan R.

---

From: Juha Heinanen <[email-masked]>
Date: Thu, 3 Jan 2002 10:15:32 +0200

> b. When in doubt, use TCP.

in a public setup, any sip entity is always in doubt, because it can at
any point receive a long message with many record-route headers, for
example.  it would thus always use tcp, which means that we have no
other simple way to solve the problem than to deprecate udp.

-- juha

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 03 Jan 2002 11:17:41 +0200

Hi,

>other simple way to solve the problem than to deprecate udp.

I do NOT have anything against adding a response code, if such is really
needed, telling that the message was too long, and could therefor not be
processed.

We should, however, remember that there are two cases here:

1. Proxies add headers (R-R ect) to a request. Suddenly the request
message becomes too long for the network to handle (using whatever
method to find out about that), and the response code is sent back.

2. The request does reach the UAS, but it then finds out that the
response message will become too long.

For the second case we should also remember that the response message
may not become too long when it's sent by the UAS, but later in the
network if proxies add headers to the response message (this may happend
ie if some kind of header hiding is used).

HOWEVER, I think it shall then be an IMPLEMENTATION ISSUE what the
receiving node does when it receives that response code. The node MAY
choose to use another transport protocol, the node MAY choose to use
some compression mechanism, the node MAY choose to shorten the message
ie by removing some optional information, the node MAY choose to
terminate the call setup. And, in a forking scenario there are many
different things the node can do - thing which may be configurable, or
chosen using some other kind of policy. And, the action(s) taken most
likely also depend on what kind of node (gateway, SIP phone, proxy...)
where the response is terminated, so I don't want the spec to say that
one always MUST do this and do that...

AND, I do NOT support the removal of UDP :)

Regards,

Christer Holmberg
Ericsson Finland

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 03 Jan 2002 03:14:48 -0500

> it (like some other errors) back to the UAC. The UAC can then originate

There are many problems with this. One, is that even though the UAC may 
re-originate with UDP, there is no guarantee that the next hop will do so.

Also, the 499 may not actually be propagated back to the UAC in the case 
of forking; thus, this would add additional cases that trigger the 
HERFP. I'd rather avoid that.

Resubmitting at each hop to the exact same next hop makes things a bit 
easier. Now, I agree its messy and I would indeed rather have a simpler 
solution.

-Jonathan R.

---

From: Michael Thomas <[email-masked]>
Date: Thu, 3 Jan 2002 08:57:58 -0800 (PST)

> things of having a transport independent protocol.

   So what happens when the sprawling operations of
   softarmor.com and mtcc.com need to put their
   Very Important CEO's in touch?

		  Mike

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 04 Jan 2002 08:01:25 +0200

Hi Mike,

I am not really sure I understood your question, but I assume that you
meant that you want TCP to be used for the CEO, while others can use
UDP. Right?

We should remember that the SIP SIGNALLING is only a small part of the
messages sent during session, so from that point of view I think the
session with the CEO will be established no matter what transport
protocol is used, even if some UDP fragments of the INVITE is lost and
must be re-sent.

The MEDIA, however, will still be transported on UDP (in an IP bearer
network using RTP), so if there are lots of delay and packet losses in
the network your CEO isn't going to be too happy anyway - even if he got
the INVITE in a "nice and reliable" way.

Again, I appologise if I missunderstood your question :)

Regards,

Christer Holmberg
Ericsson Finland

---

From: Michael Thomas <[email-masked]>
Date: Fri, 4 Jan 2002 08:23:33 -0800 (PST)

Sorry -- perhaps a bit too obscure. The point I'm
making is that an "operator" may in fact be very,
very small so that any supposed site-wide policy
may be inconsequential, and the likelihood of
peering arrangements negligible. SIP needs to work
in cross realm settings large and small equally
well. Therefore we can't hand wave this issue away
by saying that it can be dealt with as a general
issue with peering with well defined peering
points. That is very likely how large operators
will set up their networks, but that does not
scale for lots of very small SIP deployments.

	  Mike

---

From: Dorgham Sisalem <[email-masked]>
Date: Sun, 6 Jan 2002 15:20:26 +0100

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
 message was fragmented into two or three messages of which all will
 have to be retransmitted when one is lost should not cause congestion,
 specially when considering that the signaling traffic will most
 probably be only a small portion of the overall traffic. If we
 expect that the SIP signaling messages will get really big so that we need to
 worry about congestion then I believe something went wrong with the
 protocol design).

 What is more worrying naturally is when SIP is used to send
 messages with large bodies. In this case the sender should refer to
 TCP directly or divide the body into different messages and and send
 them in a TCP like fashion (only send a message when the previous one
 was acknowledged) thereby the SIP loss handling mechanisms would deal
 with the congestion avoidance.

 Cheers

-- 
Best regards,
 Dorgham                            mailto:[email-masked]

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Sun, 06 Jan 2002 12:52:20 -0500

>  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.
-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 17 Jan 2002 16:04:25 -0500

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.

Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 18 Jan 2002 09:12:04 +0200

Hi,

Just a small comment on point (1). A case where the response may be much
bigger than the request is when we send an INVITE without SDP, and
receive a 200 with SDP. Now, I am NOT saying this is a problem, and it
could probably also be classified as "in most cases it won't happen". 

At least I can't remember when I would have seen it in a real-life
scenario. But, maybe people doing SIP/H.323 interworking have some info
on this?

Regards,

Christer Holmberg
Ericsson Finland

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 21 Jan 2002 11:39:07 -0500

> could probably also be classified as "in most cases it won't happen". 

Actually, it is a common case for 3pcc.

Nonetheless, I still feel the proposal is a reasonable point of 
compromise, covering a good number of conditions without doing 
substantial damage to SIP.

-Jonathan R.