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(_at_)ietf(_dot_)org 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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf