Subject: tsv-dir review of draft-ietf-sip-outbound-17

From: Colin Perkins <[email-masked]>
Date: Mon, 25 May 2009 13:51:37 +0100

I've reviewed this document as part of the transport area  
directorate's ongoing effort to review key IETF documents. These  
comments were written primarily for the transport area directors, but  
are copied to the document's authors for their information and to  
allow them to address any issues raised. The authors should consider  
this review together with any other last-call comments they receive.  
Please always CC [email-masked] if you reply to or forward this  
review.

Overall, this draft is basically ready for publication, but has some  
minor nits that should be fixed before publication.

The initial paragraph of section 3.5 can be interpreted as implying  
that a single lost ping is sufficient to declare a UDP flow dead.  
Section 4.4.2 is clear that this is not the case, but to avoid  
confusion, it might be appropriate to add a caveat or forward  
reference to section 3.5.

Section 4.4 defines a keep-alive mechanism using CRLF sequences  
multiplexed with the SIP messages if connection-oriented transports  
are used, and using STUN requests sent on the same port when  
connectionless transports are used. This makes sense for the examples  
of TCP, SCTP, and UDP transports. There's no mention of DCCP, though,  
which has somewhat different properties to the other connection  
oriented transports, and doesn't obviously work using a CRLF keep  
alive (e.g. RFC 3261 section 7.1 requires implementations that use  
stream-oriented transports to ignore an extra CRLF, but not those  
using unreliable datagram protocols). Some clarification would be  
useful, even if just to state that operation over DCCP is for future  
study.

Section 4.4.1 specifies keep-alive timer intervals for connection- 
oriented sessions for both battery operated and mains powered devices,  
while section 4.4.2 only provides a single time out value for  
connectionless sessions. It would be useful to explicitly mention the  
impact on battery powered devices in section 4.4.2, to be clear that  
the suggestion of only a single interval was intentional.

Section 4.4.1 requires a response to a keep alive to be received  
within 10 seconds of the request being sent. It's not clear why this  
value was chosen, especially since multi-second RTTs are not unheard  
of in some cases (c.f. the motivation for LEDBAT). While I don't think  
this is an inappropriate choice, some motivation and rationale would  
make it easier to judge why this value is sensible, and when it might  
be appropriate to use a different time out.

-- 
Colin Perkins
http://csperkins.org/