Evaluation: draft-ietf-sip-sctp-03.txt

[hardie@qualcomm.com]

Ted Hardie          [   ]     [   ]       [ x ]      [   ]

Overall, I think this is good, interesting work.  I'm not sure I understood
two small things, though, and I'd like help understanding them.  In 
Section 3.2,
one of the descriptions for advantages over TCP contains the following:

             On the other hand, SCTP can deliver
             signalling messages to the application as soon as they
             arrive (when using the unordered service). The loss of a
             signalling message does not affect the delivery of the rest
             of the messages. This avoids the head of line blocking
             problem in TCP, which occurs when multiple higher layer
             connections are multiplexed within a single TCP connection.
             A SIP transaction can be considered an application layer
             connection. Between proxies there are multiple transactions
             running. The loss of a message in one transaction should
             not adversely effect the ability of a different transaction
             to send a message. Thus, if SIP is run between entities
             with many transactions occurring in parallel, SCTP can
             provide improved performance over SIP over TCP (but not SIP
             over UDP; but SIP over UDP is not ideal from a congestion
             control standpoint, see above).

This seems to imply that SIP over SCTP is expected to be used commonly
only between proxies or other entities that meet the test "entities
with many transaction occurring in parallel".  Is that a strong enough
expectation that an explicit applicability statement to that effect 
would be useful?
It seems to be implied, but having that inside a section on comparisons
between SCTP and TCP may make it less than obvious.

In the section on mapping SIP transactions into streams, the document says:

   Some applications introduce an extra layer between the transport
   layer and SIP (e.g., compression and/or encryption). This extra layer
   sometimes requires ordered delivery of messages from the transport
   layer (e.g., TLS [6]). In this case, it is RECOMMENDED that SIP
   messages belonging to the same transaction are sent over the same
   stream and messages belonging to different transactions are sent over

I wonder whether there are not applications which introduce the same
requirement because of the semantics of their use of SIP itself, rather
than because of layering.  In particular, I wonder whether session-mode
message (draft-ietf-simple-message-sessions-01.txt) would or
would not require the same treatment.  If not, I suspect that this implies
that those applications either should not pipeline requests (since a proxy
may be using a transport that does not guarantee ordered delivery) or
they must be able to handle the resulting failure mode in some graceful way.

Notes:

Section 3.1:  Looks like a minor grammar error in this sentence:
"IP  fragmentation increases the likelihood of having packet losses
and make it difficult (when not impossible) NAT and firewall traversal."
Changing it to "and making it difficult (when not impossible) to traverse
NATs or firewalls" would fix it, as would several other choices.

Section 4.  A couple of minor preposition questions:
   "The SIP transport layers of both peers are responsible to manage the
					       for managing?
   persistent SCTP connection between them. On the sender side the core
   or a client (or server) transaction generates a request (or response)
   and passes it to the transport layer. The transport sends the request
   to the peer's transaction layer. The peer's transaction layer is
   responsible of delivering the incoming request (or response) to the
                     for delivering?
   proper existing server (or client) transaction."