Multiple parameters on 'a' line: Please do help me understand

[James_Renkel at 3com.com]

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