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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 tsv-dir@xxxxxxxx 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/



_______________________________________________

Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]