Multiple parameters on 'a' line: Please do help me understand
James_Renkel at 3com.com
James_Renkel at 3com.com
Wed Jul 31 13:08:18 EDT 2002
Flemming (and other modem experts),
Sorry for the delay in responding to this. Been real busy.
On 07/12/2002, at 10:21:09 A.M., you wrote, in part:
> > It's really unambiguous (Assuming ya got all the commas right! :-) ),
> > and
> > pretty compact and concise.
> All true, but as you note, you'd better not get those commans wrong. It's
> fairly error prone and not very easy to debug.
Since the SDP is generated and parsed by computers, not humans, getting
the commas right is no better or worse than, e.g., getting the spelling
of attribute names right. IMHO, not a problem either way, nor is it all
that hard to debug either.
> > On the issue of SIP/SDP transaction size. yah, we're probably OK for
> > But the way and rate things are being added I'm just afraid we're gonna
> > be in trouble soon.
> What kind of trouble ? SIP allows you to use TCP (or SCTP for that
> if UDP fragmentation is your concern, you already have a solution. Also
> that SIP allows you to use compression to reduce the size of messages,
> clearly, text is fairly compressible.
I have several concerns with using either TCP or SCTP rather than UDP
here, or with doing anything that might directly or indirectly require
the use of TCP or SCTP:
1. As you correctly state, TCP and SCTP are allowed by SIP, while UDP is
required. But the result of this is that some endpoints and proxies only
implement UDP, and not TCP or SCTP. If TCP or SCTP were required for
sessions including MoIP (or the only real alternatives available because
of, e.g., transaction sizes), then those endpoints and proxies would have
- implement TCP or SCTP in order to make their MoIP implementations most
- not implement MoIP.
I would prefer to not have to force implementers to make that choice. We
can do that by making sure that MoIP works well with UDP.
2. Even if TCP or SCTP were (almost?) required, which one do ya use?
Some implementers may choose one, others the other. Again, interopera-
bility problems. IMHO, better to stay with one (UDP) that everyone can
and does use.
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
- NOT have a TCP connection open to each of them simultaneously, because
of the latency in opening a TCP connection.
SCTP has the same problems. Again, the best solution is UDP.
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;
- TCP rate control is not appropriate for connections that carry
signaling for multiple simultaneous sessions and can lead to severe
SCTP was developed in response to these problems, but is not yet widely
supported and deployed. Again, IMHO, UDP is the best solution.
I will agree that text in general, SDP in particular, is very compressible
and that SIP has good support for message compression. But again, this is
an optional capability. If every endpoint and proxy supported it I wouldn't
have a problem with relying on it. And while, unlike the use of TCP and
SCTP, I strongly support and encourage the use of SIP message compression,
I don't think we should be relying on it (Until it's support is mandatory,
which I also strongly support and encourage, and is widely deployed! :-) )
> > The SDP isn't so much a problem as the SIP:
> If the problem is not in SDP, then it shouldn't be solved there. As noted
> above, there are already solutions to the SIP problem.
I didn't say there wasn't *any* problem with the SDP, or that small SDP
size could completely solve the problem. But if everybody depends on
everybody *else* to solve a shared problem, the problem never gets solved.
In fact, the problem may not get solved unless *everybody* *does*
contribute to the solution. To the extent that MoIP SDP contributes to
the problem, it has to contribute to the solution. As with ecology: think
globally, act locally.
As noted above, I disagree that the things you noted above are acceptable
solutions, except maybe for SIP message compression.
Finally, going back to the top of your message:
> Given the cons of this
> scheme, there would have to be an exceptionally strong motivation for
> (which I haven't seen).
To my mind, the issues that I've stated above provide more than enough
motivation for us to do everything we reasonably can to keep the MoIP SDP
size as small as possible.
Comments expected and welcome.
More information about the sg16-avd