Flemming (and other modem experts),

It seems as if: - We agree on a couple of things; - We agree to disagree on a couple of thing; and - A couple of things are still unresolved.

That's progress!

I'll just comment on the still unresolved things.

On 07/31/2002, at 01:45:07 P.M., you wrote in part:

Actually, SIP requires TCP support as well.

<snip>

If they are RFC 3261 compliant, then they implement TCP.

Oh, boy, this is gonna get complicated. :-)

First of all, you are, of course, correct. Quoting from RFC 3261:

All SIP elements MUST implement UDP and TCP. SIP elements MAY implement other protocols.

But quoting further:

Making TCP mandatory for the UA is a substantial change from RFC 2543. It has arisen out of the need to handle larger messages, which MUST use TCP, as discussed below. Thus, even if an element never sends large messages, it may receive one and needs to be able to handle them.

For the uninitiated in the lore of SIP: 1. By reading this you are becoming initiated! Welcome to the community; 2. RFC 3261, often lovingly referred to as "2543bis", is an update to RFC 2543, but not completely backward compatible.

RFC 2543 was issued in March, 1999. RFC 3261 was issued in June, 2002, i.e., very recently, although stable drafts have been around for a little while before that. So, it's not surprising that much (most? all?) deployed SIP gear isn't yet RFC 3261 compliant.

And, of course, as modem experts know all too well that, just because a new version of a standard becomes available, it does not mean all implementations will be upgraded soon. And just because an implementation upgrade becomes available doesn't mean all deployed equipment will be upgraded with it.

So, unfortunately, we're gonna have to live for some time with equipment that is only compliant with RFC 2543, and not also compliant with RFC 3261 (If such a thing were possible.).

So, you ask, what does RFC 2543 have to say about all this? Here's where it gets real interesting!

Quoting from RFC 2543:

User agents SHOULD implement both UDP and TCP transport. Proxy, registrar, and redirect servers MUST implement both UDP and TCP transport.

Very precise for proxies, etc. But talk about wiggle room for user agents, i.e., endpoints: ya should do both, ya hafta do one, but which one is up to you!

So, you ask, what did RFC 2543 compliant endpoints do? Some of them implemented both TCP and UDP, some of them only implemented TCP but some of them only implemented UDP. Potential interoperability problems abound if endpoints talked SIP directly with each other. But that's rare: ya almost always go through at least one proxy.

So, unfortunately, we're gonna have to live for some time with endpoints that only support UDP. It's not the majority of endpoints, thank you for small favors, but there are enough that they can't be ignored.

So, you ask, what's the problem? If they're not gonna be upgraded to be compliant with RFC 3261, they almost certainly won't be upgraded to support MoIP. So why should we worry about them?

Well, ya still gotta interoperate with them. Customers (at least carier customers) demand that, and check for it in their certification tests.

And unfortuately, ya don't know in advance, when ya launch a SIP INVITE transaction into the signaling network, even if you launch it via TCP so transaction size isn't a problem, whether the endpoint at which the INVITE will eventually wind up supports RFC 3261 or not, supports MoIP or not, or more importantly whether it supports TCP or only UDP.

And most importantly, if the remote endpoint only supports UDP and your INVITE is too big, ya can't get (enough of) the INVITE there so ya could find out in its response that it doesn't support MoIP and then re-INVITE with MoIP in your SDP so, hopefully, the re-INVITE is now small enough to be carried by UDP. Even if ya wanted to do that, which I neither want to do nor recommend doing.

Ya, there's other kludges, I mean, work arounds, but they don't always work.

So basically, that means ya gotta get it, the initial SIP INVITE for a new call / session, right the first time.

And that means keeping the INVITE small enough so it can fit in a single UDP packet, if at all possible.

Flemming: I suspect that this is one of those things on which the best you and I will be able to do is to agree to disagree. :-(

I'm all for UDP support as well (although not as much as I used to be) <snip>. Besides, Rajesh's proposal does in no way prevent UDP from being supported, so I don't see a big issue here.

Well, if the SDP for MoIP is so large that, in combination with the "largeness" of the SIP transactions that carry it, it doesn't fit in a single UDP packet, then we've got problems.

...

3. For proxies that support thousands or tens of thousands of endpoints

simultaneously, it is impractical for them to:

• have a TCP connection open to each of them simultaneously, because of resource consumption; and

How much of a real problem is this actually ? Do you have any hard data

to back

this up ?

We have data how many endpoints carrier customers expect a single SIP proxy to support simultaneously, and what resources our SIP proxies require per simultaneous TCP connection. I'll see if any of this can be made available. But, ya, we see this as a real problem.

Since the world wide web is based on TCP, that's pretty good evidence that the TCP scalability problems

perhaps are

not all that severe.

HTTP connections tend to be very short lived, so an HTTP server, and we're talking a *big* HTTP server here, while it may be serving thousands of browsers simultaneously, seldom has more than a few hundred TCP connections open simultaneously. Even streaming media servers seldom have more than a few hundred connections open simultaneously.

Endpoint to proxy connections tend to be long lived (Especially if there's a NATter in between! :-) ), so it's not uncommon to see a carrier class SIP proxy, and to be fair we're talking a *big* SIP proxy here, have thousands of TCP connections open simultaneously.

...

• NOT have a TCP connection open to each of them simultaneously,

because

...

of the latency in opening a TCP connection.

This presupposes that you need more TCP connections than you can handle.

Actually, it presupposes that you need TCP connections, which sometimes ya just gotta have. But to the exteant that you can use UDP instead of TCP, life is made easier. Sometimes, a lot easier.

...

SCTP has the same problems. Again, the best solution is UDP.

Not necessarily. By using UDP you have to address a multitude of issues

<snip> the best solution is probably not always UDP.

Yup, UDP has it's own set of problems. I'm not suggesting that UDP is *always* the best solution. But we have to be careful that we don't, indirectly, cripple UDP so bad that it can no longer be a solution where it used to be. If an implication for a carrier customer of supporting MoIP is that all or most existing UDP usage has to be changed to TCP (or SCTP), well, that carrier is gonna have severe problems with MoIP.

...

4. In multiport gateways, reusing a single TCP connection for multiple

simultaneous sessions has several problems:

• TCP requires sequential delivery: if a segment with signaling in it for one session needs to be retransmitted, segments behind it, with signaling for other sessions, are delayed; hence, many sessions can

be

...

delayed because of a retransmission in another session's signaling;

Right - the famous head-of-line blocking issue. However, there's also an advantage to it, which is that lost datagrams can be detected much faster

by

TCP in these cases than a pure UDP solution can, since the UDP solution

can

only rely on a timer firing to trigger a retransmit.

The problem is where the carrier has SLA performance guarantees. Then the carrier is gonna benchmark average SIP transaction processing time as part of its pre-deployment certification.

If I have a choice between: - one transaction being delayed 1 second and, say, 99 transactions that are queued behind it not being delayed (because UDP is used); and - 100 transactions being delayed 0.1 seconds each (because TCP is used) well, if I'm worried about my average SIP transaction processing time, I may take the first option and use UDP.

My concern is that MoIP may preclude that option if the SDP is too big.

...

• TCP rate control is not appropriate for connections that carry signaling for multiple simultaneous sessions and can lead to severe performance problems.

I strongly disagree with the implication of this statement. <snip>

After re-reading the way I wrote this, I strongly disagree with the implications also!

What I was trying to say, but didn't say very well, is that so-called "TCP-like" rate control, as opposed to so-called "TCP-friendly" rate control, is not appropriate here, with the implication that TCP-friendly rate control is appropriate here.

I didn't mean to suggest that the use of *no* rate control was appropriate, but I see now how what I wrote could, and probably would, be read that way.

For those uninitiated in the lore of packet network rate control: 1. You're now getting initiated! Welcome to the community. 2. Transmission rate control is absolutely essentially in packet networks to give fairness to all users and prevent congenstion collapse. 3. TCP-like rate control is designed for applications like file transfer (e.g., HTTP, FTP, SMTP, etc.) where maximum fairly available bandwidth is desired and *severe* decreases in transmission rate because of congestion are acceptable. 4. TCP-friendly rate control is designed for rate limited applications like streaming media (and multiplexed signaling streams) that might not be able to take advantage of the maximum, fairly available bandwidth and only small decreases in transmission rate due to congestion are acceptable; essentailly, in very simplified terms, it trades off the bandwidth upper limit for the bandwidth lower limt.

The point is that with TCP you can only use TCP-like rate control, not TCP-friendly. With UDP (I'm not sure about SCTP, but probably there, too.) ya can use TCP-like or TCP-friendly rate control, it's up to you.

(Actually, UDP does require *any* rate control, and if it is used it gets implemented above UDP. This concern is what led to the developing of DCCP: rate control is required; and both TCP-like and TCP-friendly are available.)

So again, UDP gives me an option that TCP doesn't, and we have to be careful that we don't make UDP no longer an option.

<snip> The best guideline is simply to follow what the IETF has already done with SDP and SIP <snip>

Hmmm, I seem to remember that the IETF had problems with the SDP for T.38 / FoIP (And the SDP in a couple of other RTP profile proposals) because, well, it was too big and defined too many attributes, thus potentially requiring too many attribute lines.

What's too many? Good question, but I have little doubt that, since MoIP has more potential parameters than FoIP first proposed, if we propose coding them one per attribute line, the IETF ain't gonna like it. FoIP solved the problem by reducing the number of parameters overall and the number of parameters that were mandatory. Maybe we should do the same thing.

But that takes consensus of the group. Lacking that consensus, I did the best I could and put multiple parameters per attribute line. Multiple parameters per line of SDP is not without precedent. Delimiter, as opposed to whitespace, separation maybe is. But without delimiters, ya gotta code every leading parameter value, ya can't let any of them default, which leads to, you guessed it, bigger SDP.

Sorry if that ain't the way the IETF does it. I to have to say, and I'm not sorry about it, that there are quite a number of the things the IETF does that I wouldn't do if it were up to me. I guess I'm just not a lemming, but everybody knows that. :-)

I would suggest you try and contact the relevant IETF Working Group Chairs and/or Area Directors <snip>

Scott Bradner is planning on sitting in on the Waltham meeting on Friday morning. Perhaps we should put some of these issues to him?

'Nuff for now. Way more than enough. :-)

As always, comments are welcome, expected, and appreciated.

Jim