Comments on draft-ietf-tsvwg-sctp-udp-encaps-03

[Brian Trammell <[e-mail]>]

Greetings, all,

Apologies for missing the WGLC end on this draft; however as it appears it may be rev'd anyway on the MTU DF question, I hope the following comments prove useful.

I've reviewed the document. It fills a need and the approach makes sense, so I'm in favor of its publication. I do have a couple of suggestions for clarification, though none of these change the normative content of the document. I'll state that my perspective here is as an SCTP application developer, and as someone interested both in this draft and draft-tuexen-tsvwg-sctp-dtls-encaps within the context of IPFIX over SCTP. (I'll also state that I didn't follow the WG discussion on this draft to date, as I only sporadically pay attention to tsvwg, so apologies if some of these comments are old news.)

I'm still a little confused about how exactly UDP port mappings to SCTP associations are meant to work in practice. Clearly, there is one UDP port per "stack": one per application with application-bound SCTP-over-UDP and one per host, defaulting to 9989, with SCTP-over-UDP in the kernel or via a (probably privileged) userspace SCTP-over-UDP daemon. This point might be made more clearly in section 4.1 -- that there are really two envisioned deployment scenarios (or three, depending on how you count), and explicitly spelling out the recommended port numbering for each.

(This opens an issue at the user interface level, though I am reasonably certain this is out of scope for this document. Now you potentially have one port that is exposed to the user or inherent to the application (the SCTP port), plus one port that may have to be exposed to the client or not based on the deployment scenario in use at the server. There are ways for dealing with this with a single port in user- or administrator-exposed names (URIs, DNS SRV...) but I don't know how well this works for two ports. 
Again, I'm not sure it fits in this document at all, but some discussion of this issue (and suggested solutions) somewhere would keep each application developer or specifier of application protocols from having to solve it themselves. This issue would appear to apply to draft-tuexen-tsvwg-sctp-dtls-encaps as well.)

There are a couple of other bits that were terse to the point of being a little unclear on a first reading. In section 4.2 it may be helpful to point out that the point of UDP checksumming is to reduce the chance of UDP header corruption. (I had to think about this for a couple of seconds; SCTP has its own reliability mechanisms, after all...) Likewise, section 4.8 might benefit from a note that you're talking about ECN bits in the IP header, and that ECN over SCTP works otherwise as specified in draft-stewart-tsvwg-sctpecn (with an informative reference).

Best regards,

Brian