[EMAIL PROTECTED] wrote:
Comments on draft-ietf-sip-connect-reuse-08.
Overall:
The mechanism defined in this I-D is sensible and useful. The
writing could be improved significantly.
Dale: Thank you for your in-depth review and feedback. More inline.
Major technical:
Section 10, "Support for Virtual Servers" explains the necessity of
certain elements of the connection-reuse mechanism. But as far as I
can tell, this explanation is incorrect (although the problem is
real).
I suspect we are not that far apart in the understanding of the problem.
In other words, the problem is indeed, as you write:
However, the virtual server problem is quite real. The fundamental
problem is that making a TLS connection to a destination involves two
distinct steps -- first, using RFC 3263 to find the address of the
destination, then second, using TLS to establish *and authenticate* a
connection. Only if both steps succeed is the connection available
for sending the message. As such, the "alias table" must cache not
only which connections go to which destination addresses, but which
connections have authenticated themselves as responsible for which
SIP domains. If a message is to a *new* SIP domain that resolves to
an address with a cached connection, the cached connection cannot be
used, because the connection is not authenticated for the new domain.
That is precisely why the alias table supports the "Destination
Identity" column.
I take it that the text describing the virtual server problem needs
to be made much more clear. I will do so in the next revision,
using your comments as a guideline.
Editorial:
Overall
Excessive text is spent on the cases of TCP and SCTP without TLS. As
far as I can see, they are to be handled exactly as previously. It
is useful to explain why this must be so, and section 9.3 does so,
but I don't see the need for the page-long section 5.2 and 5.3.
By "exactly as previously", do you mean handled as TLS? If so,
then I would disagree since for the TLS case, you can indeed only
use one connection, but for TCP and SCTP without TLS you will
need two connections. S5.2 disambiguates TCP connection reuse
from TLS reuse, thus I believe it is relevant (S5.3 is basically
a short two-paragraph section discussing SCTP for completeness.)
The description focuses on the "alias table", making that particular
implementation quasi-standard. But I don't see the mechanism as
being complex enough to require describing that specific
implementation in order to make the mechanism clear.
The intent is not to make the alias table quasi-standard. Rather,
it is easier to follow the subsequent discussion based on the
information presented in tabular format. In reality, many robust
SIP implementations probably already include such a table anyway. So
I do not see the harm in the continued use of the metaphor.
A few definitions are given, but various terms that are used with new
meanings are not defined. E.g., "establish an alias" meaning "the
destination of a connection deciding that the connection can be used
in the reverse direction, that is, for sending requests".
OK; I will go through and attempt to catch some of the undefined
terms.
Examples tend to discuss multiple user agents and proxies, when the
entirety of the mechanism can be described by considering only the
two SIP agents at the ends of the connection. I think the intention
is to make the examples more realistic, but instead the examples get
more complex and hard to follow -- especially because the discussions
often aren't meticulous about specifying which agent sends which
message to which agent. (Not to mention that the discussion suggests
that user agents and proxies might participate in this mechanism in
different ways, whereas connection-reuse treats user agents and
proxies identically.)
Correct; any remaining ambiguity you see is my failure at
delineating what belongs to outbound and what should remain in
connect-reuse. I will be more diligent about this in the next
revision.
The use of "alias descriptor" is unfortunate. To start with, it is
confusing -- initially I mistook it for some sort of identification
of the row of the alias table. But the concept of "descriptor" as
being a small integer identifying a network connection, as well as
the very term "descriptor", are Unix-specific.
Anything wrong with that :-) ?
Much better would be to use a neutral term like "internal connection
identifier" and to represent the value by something like "XXXX".
As a programmer, I find it convenient to refer to the connection
identifier as a descriptor. With your permission, I would like to
continue using that analogy.
There is an overall conflating of two concepts as "connection reuse".
One is using one connection to send more than one request from one
sender to one recipient. The second is using one connection to send
requests in both directions. The first concept is already supported
by RFC 3261; the second is what is being enabled by this I-D. But
the I-D implements both actions using one alias table, obfuscating
the distinction and so obfuscating the changes that the I-D is
introducing.
So this is an interesting and very relevant comment. You are
absolutely right that there are indeed two concepts of connection
reuse. However, I do not believe that the draft conflates them.
What you term as the "first concept" is indeed mentioned in rfc3261,
but not in the form that connect-reuse is exalting. More specifically,
S18 of rfc3261 talks about persistent connections, and how an
implementation should keep connections open to send subsequent
requests over the same connection. However, rfc3261 also mentions
that the duration a connection stays open should be at least as
long as 64*T1 seconds. Thus, I have observed implementations that
keep a connection open as long as 64*T1 seconds and no more, and
some even less than that.
As a result of that observation, the text in connect-reuse exhorts
implementations to keep the connection open for as long as they can
(i.e., close it when resources need to be reclaimed using some
strategy like closing the least actively used connection, or the
connection that has been open for the longest time, etc.)
Details
[...]
All of the details you point here are excellent, and will be
included in the next revision of the draft.
Thanks for the WGLC review, Dale.
Regards,
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
Email: [EMAIL PROTECTED],bell-labs.com,acm.org}
WWW: http://www.alcatel-lucent.com/bell-labs
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
