Subject: RE: [Sip] issues on TCP support and Record-Route

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 28 Aug 2001 17:30:28 -0400

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, August 24, 2001 7:05 PM
> To: [email-masked]
> Subject: [Sip] issues on TCP support and Record-Route
> 
> 
> I am sorry if these issues have been discussed before. I have 
> two issues
> concerning carrier grade SIP applications.
> 
> (1) When using a stream based transport protocol, e.g., TCP, SIP poses
> several problems because SIP messages don't carry total 
> length in a fixed
> position, e.g., the first 4 bytes of the messages:
> 
> (a) Although the messages can be parsed in normal conditions, 
> our tests
> showed that the performance of using current SIP spec is several times
> slower than carrying a total length in front of SIP messages.

Several times! Yikes! Our performance results show a small decrease in
performance (on the order for 10%), and we suspect that has a lot more to do
with issues surrounding buffer sizing, delayed ACK, etc. Sounds like a
problem with your implementation, rather than a fundamental problem with
length indicators.

> 
> (b) There is no robust way to handle malformed messages 
> coming from TCP
> without a total length in a fixed position. For example, a 
> message doesn't
> have a correct end of message headers.

The spec talks about how to handle the case where the length is not present.
If its wrong, you end up with an overly long or overly short payload, which
results in an error being generated.

All of this seems to work for HTTP, which supports persistent connections
even, so I have a hard time believing its unworkable for SIP.

> 
> So what is the reason that SIP doesn't specify a total 
> message length in a
> fixed position. I propose to carry a total length of each 
> message in the
> first 4 bytes for stream-based transport protocol.

Well, this is more of a transport issue. Sounds like what you are asking for
is message oriented connection transport. SCTP provides such a thing.

> 
> (2) The Record-Route header has been overloaded to be used by 
> subsequent
> requests in both directions. This causes problems when one 
> side of proxy
> uses TCP and the other side uses UDP, although bis-4 does 
> allow Record-Route
> header to carry "transport=value" parameter. Some people have 
> suggested to
> rewrite the Record-Route header for final responses. This 
> suggestion posts
> performance overhead for all final responses.

Sure, but no more than any other response processing thats done in a proxy
(like stripping a via header). Compared to the rest of the overall
transaction processing, I suspect that the overall contribution to
performance for rewriting the RR in a 2xx is tiny, so fixing this is not
likely to do much for you.

 I propose to 
> use different
> names when specify transport protocol parameters, e.g., transport_in =
> TCP;transport_out=UDP.

I'll also note that it is often necessary to specify a different port and IP
address, so that this would not be sufficient.

-Jonathan R.

---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (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: [email-masked]
Date: Tue, 28 Aug 2001 16:46:09 -0600

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]]
Sent: Tuesday, August 28, 2001 3:30 PM
To: Wang, Jin-Gen; [email-masked]
Subject: RE: [Sip] issues on TCP support and Record-Route

[Jin-Gen Wang] I don't think this is related to buffer sizing, etc. I do
agree that it's implementation related. I am not convinced it's a small
overhead unless some people can show their results. Even 10% is not trivial.
Again, I am talking about carrier grade software.

If it has been raised several times before, it may indicate there is an
issue. I am not sure how many applications using TCP are there in a high
stress environment. Other people may raise this issue again in the future.

[Jin-Gen Wang] If one message is missing end of headers or has incorrect end
of headers, the next message will be skewed. This is not acceptable for
processing phone calls. I am not sure how many people use HTTP to do phone
calls.

[Jin-Gen Wang] After all, SIP is message oriented. It happens that UDP
packets encapsulate messages for you. But for TCP, it's different. I haven't
seen a solid reason NOT to carry the message length in a fixed position. The
protocols I have seen in telecommunications so far carry length in fixed
positions. 

What damage will it cause if we do carry the message length in a fixed
position?

[Jin-Gen Wang] I think you also need to do this rewriting for other final
responses. But if we can avoid such overhead in a standard way, why not?

 I propose to 

[Jin-Gen Wang] I agree. I just want to bring up an example because we will
still have a problem in the following scenario:

UAC ---(UDP only) ---> PS1 --- TCP ---> PS2 --- UDP ---> UAS.

Let's say PS2 rewrite Record-Route to use TCP for 2xx coming back from UAS.
Now if PS1 does not record-route, UAC will see TCP as transport protocol to
send BYE over which it cannot honor. I think there are issues regarding the
use of Record-Route header in mixing transport protocol scenarios.

-Jonathan R.

---

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 29 Aug 2001 11:31:43 -0400

> Sent: Tuesday, August 28, 2001 6:46 PM
> To: [email-masked]
> Cc: [email-masked]
> [Jin-Gen Wang] I don't think this is related to buffer 
> sizing, etc. 

Do you have concrete proof that says that the overhead of not having a
length indicator is going to be the primary source of the reduction in
throughput? 

> I do
> overhead unless some people can show their results.

Those are our results. Whether you choose to believe me or not is your own
choice.

> processing phone calls. I am not sure how many people use 

If the length field you are proposing is too long, not present, or too
short, the next message will also be skewed. The failure cases seem
identical. 

> What damage will it cause if we do carry the message length in a fixed

Total destruction of backwards compatibility with every single TCP enabled
SIP element? Re-invention of message-oriented connection oriented
transports? My question still remains - if you think this is such a problem,
what is wrong with using SCTP which does what you are asking for?

> responses. But if we can avoid such overhead in a standard 

Because it breaks backwards compatibility. Because it is not clear it
provides any concrete benefits. Unkown benefit + high cost - how is that a
wise design choice?

> use of Record-Route header in mixing transport protocol scenarios.

This is a well known problem, for which text in -04 already discusses. I
have improved this text further in -05, and the issue has already been
discussed extensively on the list. You cannot RR with a transport param not
equal to UDP unless you are in a private network where you know the
transport capabilities of the hop that RR's on the side you wish to use a
different transport.

-Jonathan R.
---

---

From: [email-masked]
Date: Wed, 29 Aug 2001 10:16:43 -0600

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]]
Sent: Wednesday, August 29, 2001 9:32 AM
To: Wang, Jin-Gen
Cc: [email-masked]
Subject: RE: [Sip] issues on TCP support and Record-Route

[Jin-Gen Wang] Again, our tests showed this is the reason. Again, I agree
the percentage of reduction is implementation related. However, even in your
implementation, 10% drop is not trivial.

One disadvantage of the design (no length field in a fixed position) is that
we have to mix message parsing with each TCP connection. This limits the
choice of implementations.

[Jin-Gen Wang] I agree. This is the same if the content length in the
current spec is mal-formed. However, when the message length is correct, we
can catch all sorts of mal-formed SIP messages without affecting the next
message, which is much more robust in my opinion. Again, I am talking about
carrier grade software (at least four 9s reliability).

[Jin-Gen Wang] The backward compatibility is a very legitimate concern.
However, that doesn't mean we shouldn't change anything. I am trying to
understand the protocol design idea behind  missing message length in a
fixed position. I haven't seen a solid reason yet.

It seems to me that to force people using SCTP in our case is against "the
transport protocol neutral principal" of using SIP. 

[Jin-Gen Wang] Again, it seems to me that this is against "the transport
protocol neutral" principle of using SIP. If it is a well known problem,
doesn't that mean the Record-Route idea needs to be looked again?

-Jonathan R.
---

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 29 Aug 2001 17:23:14 -0400

> Sent: Wednesday, August 29, 2001 12:17 PM

So? 

> carrier grade software (at least four 9s reliability).

The class of malformed SIP messages which can be caught by your proposal,
but not the current approach, assuming the Content-Length itself is formed
correctly, is only ONE. That one case is where there is no double CRLF after
the last line (unless your parser is really bad, but breaking the protocol
to handle the inability of people to build a good parser is not a good
design choice). I am curious how frequently you are seeing implementations
not include that double CRLF. I have never seen it. Let us please discuss
real problems. 

Perhaps you can point to some real data that says that for HTTP, this
"problem" occurs some reasonable percentage of the time?

> transport protocol neutral principal" of using SIP. 

Different transports provide different benefits. SIP works with stream and
message transports. You are saying that you like message transports that
provide a lower layer length indication. OK, so use one.

> doesn't that mean the Record-Route idea needs to be looked again?

It is a well known problem with documented solutions in bis-04. You
questioned the design decision by proposing a "better" solution that breaks
all backwards compatibility, in the interests of carrier grade. I have
argued that there is no proof that the current design decision cannot work
in carrier grade environments. Just because something requires "processing"
to be done, says nothing about whether eliminating or speeding up that
processing improves overall performance. Amdahls law, remember....

-Jonathan R.

---

---

From: [email-masked]
Date: Wed, 29 Aug 2001 16:32:55 -0600

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]]
Sent: Wednesday, August 29, 2001 3:23 PM
To: Wang, Jin-Gen
Cc: [email-masked]
Subject: RE: [Sip] issues on TCP support and Record-Route

So? 

[Jin-Gen Wang] (1) A good protocol/architecture design should leave the
implementation enough freedom. (2) In general, this is against component
software design to implement SIP. I don't think it's a wise decision.

[Jin-Gen Wang] Let's face the reality. The best parser is to parse the
stream once, do you agree? If a start line is mal-formed, e.g., no spaces to
separate different fields. What are you going to do? One option is to read
in all lines and find Content-Length to locate the end of message. Then
re-parse the read-in buffer to indicate the mal-formed start line. This
requires multiple passes through the byte stream.

For one pass parsing, the mal-formed start line should be caught in the
first pass and discard the message. My proposal (actually a common sense
proposal for using stream based transport protocol) will make one pass
parsing work reliably. The current spec requires multiple passes to handle
such mal-formed messages which adds a lot of overhead.  

To deal with such mal-formed SIP messages is a reality for programmers.

[Jin-Gen Wang] I am not sure what you mean. The message length is on the
application level. I am hoping that the problem can be addressed in a
standard way. Otherwise, people will find their own ways to solve the
problem.

[Jin-Gen Wang] Well, it doesn't work in our environment. I am not in a
position to present our environment. You may say our environment is skewed.
The only thing I know is that the Record-Route is not working well in
mixed-transport protocol scenarios. I didn't say my solution is a better
solution. I just want to see if people have suggestions for fixing the
problem other than those in bis-04 which are not satisfactory.

-Jonathan R.

---